Bin mir nicht ganz sicher, aber versuche mal




von NSXMLParser

Hmm, sollte aber per default auf NO sein.

Implementier mal




in deinem Delegate und schau ob das angeschubst wird.

Was machst du Freitag Abend?

Warum sollte NSXMLParser die DTD online prüfen? Dann könnte man entsprechende XML Dokument doch nur parsen wenn man online wäre.

Bitte nicht NSXMLParser!

Nimm CFXMLParser oder NSXML bzw. NSXMLDocument!

Alex

Könntest du deine obligatorische Warnung vor NSXMLParser mal etwas konkreter gestalten. Sie taucht eigentlich in jedem Artikel in den dieser Begriff fällt auf, die Quelle dieses Traumas konnte ich allerdings noch nicht finden.

Ich hab mit dem schon 2/3 der Amazon Datenbestände durchpflügt und das ging ohne Probleme?!?!

"09-Feb-2004 07:26 AM Alexander von Below:
Dear Apple DTS,

I am parsing an XML document using the new NSXMLParser.
Surprisingly, the delegates receives the parser:foundCharacters message with strings like "\n\t", i.e. merely formatting characters of the XML file. The foundIgnorableWhitespace message of the delegate is never called.

My workaround currently is to check the string for whitespace like this:

- (void)parser:(NSXMLParser *)parser foundCharacters:(NSString *)string
{
...
NSString * tempStr = [string stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceAndNewlineCharacterSet]];
if ([tempStr isEqualToString:@""])
NSLog (@"Ignorable Whitespace was sent to foundCharacters!\n");
else
[currentString appendString:string];
return;
}"

Geht das bei Dir?

Der Bug steht bei mir noch als "Open"

Alex

Nö, ich krieg die Zeichen auch.

Hab ich ein Problem damit? Nein!

Characters interessieren mich nur zwischen einem Start und einem End Element. Die Implementierung in diesem Workarround würde ich auch mal als ganz schlecht bezeichnen, denn wenn die Daten zwischen zwei Tags "ignorable Whitespaces" enthalten kann ich die nicht einfach blind rausschneiden.

In den Griff bekomme ich das z.B. wenn ich beim Start Element entscheide ob dieses Element Characters enhält und dann einfach nen BOOL AcceptCharacters auf YES setze und beim Endelement wieder auf NO.

Ich sehe darin auch keinen Bug, der Parser scannt durch, das was einen Event auslöst wird geschickt und der Rest einfach als Characters.

Gruß

NEIN! Du hast das Problem nicht verstanden!

Die Datei enthält:

\t\t<tag>data</tag>

und ich bekomme: \t\tdata

Das ist Mist!

Alex

Nein du bekommst

\t\t

dann eine

- (void)parser:(NSXMLParser *)parser didStartElement:(NSString *)elementName.......

Nachricht, dann

data

dann

- (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName.......

Hier ist meine Demo. Schau Dir das testfile.xml im Editor an, und setz dann einen Breakpoint auf den foundCharacters Delegate

Da kommt als erstes ein String "\n\t", das ist doch Quatsch, oder hab ich was nicht verstanden?

Alex

Das klingt logisch ... seit drei Jahren hat Apple da aber zu meinem Verständnisproblem nichts gesagt.

Ich dachte, das wäre ignorable Whitespace. Ist es aber offenbar nicht

Alex

Beispiel:



Das ist der XML Schnipsel und das sind die Events:



Fangen wir mal an,

found Element Adresses, das wird ein Array ;

found Characters -> die Zeilenumbrüche etc. des Dokuments -> interessiert nicht, da ein Array keine Characters aufnimmt, sondern auf "Unterelemente" wartet -> klarer Fall, wird ignoriert;

found Element Person, das wird ein Dictionary;

found Characters -> die Zeilenumbrüche etc. des Dokuments -> interessiert nicht, da ein Dictionary keine Characters aufnimmt, sondern auf "Unterelemente" wartet -> klarer Fall, wird ignoriert;

found Element lastName -> wird ein String;
found Characters -> wir warten auf nen String -> stimmt!;
EndOfElement lastName -> string fertig d.h. unser "aktives Element" ist wieder Person;

found Characters -> die Zeilenumbrüche etc. des Dokuments -> interessiert nicht, da ein Dictionary keine Characters aufnimmt, sondern auf "Unterelemente" wartet -> klarer Fall, wird ignoriert;

FoundElement firstName -> wird ein String;
found Characters -> wir warten auf nen String -> stimmt!;
EndOfElement firsName -> string fertig d.h. unser "aktives Element" ist wieder Person;

found Characters -> die Zeilenumbrüche etc. des Dokuments -> interessiert nicht, da ein Dictionary keine Characters aufnimmt, sondern auf "Unterelemente" wartet -> klarer Fall, wird ignoriert;

usw. usw.

-------------------------------------------------

Wenn ich das mit nem Stapel verarbeite wird das ganz einfach.

Ich bekomme ein Startelement "Adresses" und lege ein NSMutableArray auf den Stapel.

Ich bekomme Characters -> das letzt Objekt auf dem Stapel ist das Array -> nix mit characters

Ich bekomme ein Startelement "Person" und lege ein NSMutableDictionary auf den Stapel.

Ich bekomme Characters -> das letzt Objekt auf dem Stapel ist das Dictionary -> nix mit characters

Ich bekomme ein Startelement "lastName" und lege ein NSMutableString auf den Stapel.

Ich bekomme Characters -> das letzt Objekt auf dem Stapel ist der String -> rein damit

Ich bekomme ein Endelement "lastName" und nehme das oberste Objekt vom Stapel

Ich bekomme Characters -> das letzt Objekt auf dem Stapel ist das Dictionary -> nix mit characters

usw. usw.

Das klingt logisch ... seit drei Jahren hat Apple da aber zu meinem Verständnisproblem nichts gesagt.

Na gut, daß du mal mit nem Sozialpädagogen darüber gesprochen hast

Original von kressevadder

Das klingt logisch ... seit drei Jahren hat Apple da aber zu meinem Verständnisproblem nichts gesagt.

Na gut, daß du mal mit nem Sozialpädagogen darüber gesprochen hast

"found Characters -> die Zeilenumbrüche etc. des Dokuments -> interessiert nicht, da ein Dictionary keine Characters aufnimmt, sondern auf "Unterelemente" wartet -> klarer Fall, wird ignoriert;"

Das finde ich halt eben keinen so "klaren Fall". Diese Dinge sind ignorable Whitespace, finde ich- Wozu ist die Delegate Methode sonst da?

Alex

Mhh,

ich seh das ehr so, das NSXMLParser einfach eine Art NSScanner ist, der auf die XML Elemente reagiert, alles was nicht zu einem Element gehört wird stupide als "Rest" rausgehauen.

Kann der Parser das überhaupt entscheiden? Der hat ja keine Ahnung ob "Persons" nun ein Array ist oder ein String bei dem das interessant ist. OK, dafür gibts die DTD, da könnte sich der Parser mal schlau machen was da kommt, aber ich denke einfach mal, NSXMLParser arbeitet nicht auf so nen hohen Level.

Original von below
Bitte nicht NSXMLParser!

Nimm CFXMLParser oder NSXML bzw. NSXMLDocument!

Soweit ich weiss ist NSXMLDocument einfach auf NSXMLParser aufgesetzt und benutzt ihn intern. Zumindest habe ich den Hinweis bei validateAndReturnError so verstanden.

Also kann der nicht wirklich so schlecht sein. Ich habe damit bisher auch keine Probleme gehabt.

-- hns

Original von below
Das finde ich halt eben keinen so "klaren Fall". Diese Dinge sind ignorable Whitespace, finde ich- Wozu ist die Delegate Methode sonst da?

XHTML ist ja auch XML. Und da ist erlaubt:
Keines von den Spaces ist aus Parser-Sicht ignorable.

Genaueres zum Ignorable Whitespace findet man unter: cafeconleche.org/books/xmljava/chapters/ch06s10.html

Dort ist es so mehr oder weniger als eine optionale Parser-Eigenschaft definiert bzw. wird über die DTD gesteuert.

-- hns

Original von kressevadder

Quellcode

1. - (void)setShouldResolveExternalEntities:(BOOL)shouldResolveExternalEntities

Entities sind &amp; usw. und XML definiert nur genau 5.

External sind in der (externen) DTD definierte Entities.

-- hns