XML: Namespace - Zuweisung funktioniert nicht

Hallo marabu,

Zitat:

der angegebene XPath ist jetzt korrekt für den aktuellen Kontext. Wenn trotzdem das Ergebnis nil ist, dann ist der Knoten "Folder" nicht der einzige Knoten mit diesem Namen. Du musst dann noch ein identifizierendes Merkmal mit aufnehmen, damit der Zugriff eindeutig wird.

Das war ja jetzt nur ein Test, um zu schauen, ob da überhaupt etwas gefunden wird, was bei näherer Betrachtung, wie Du schon richtig sagst, ja gar nicht funktionieren kann. Eigentlich müsste es für meinen Fall ja folgendermaßen lauten: 'Node := xmlDoc.selectSingleNode('/kml/Document');' damit ich den Ausgangspunkt, ab dem gesucht werden soll, und der vorher 'xmlDoc.documentElement' war, wieder korrekt setze.
Das funktioniert aber leider auch nicht. Und 'Node := xmlDoc.selectSingleNode('/kml/Document/*');' ebenso wenig.
Ziel ist es ja, alle Folder-Elemente - deren name-Eigenschaft ich ja nicht kenne - anzusprechen, ausgehend von einem bestimmten Punkt.

Bisher - also ohne den Namespace in der XML-Datei - war dieser Ausgangspunkt ja 'xmlDoc.documentElement'.

Diesen Übergebe ich ja an die Funktion 'ShowFolders' als IXMLDomElement.

In dieser möchte ich ja dann mittels 'nlFolders := Node.selectNodes('Folder');' alle Folder-Elemente abgreifen, und in den TreeView schreiben.
Das kann doch nicht sein, dass diese eine blöde Zeile da in der Datei all das kaputt macht, was vorher so schön funktioniert hat

**Neuromancer**

Zitat von marabu:

Was wäre wenn du dich irren würdest? Nicht auszudenken - die Verwirrung bei den Lesern, welche weniger davon verstehen als ich und du.

Nichts liegt mir ferner als dieses, ehrlich...

Ich kann nur aus Erfahrung sprechen. Und diese hat gezeigt, dass der Parser eben nicht mit Default Namespaces umgehen kann (ich habe eben gesucht, aber ich finde die Stelle im msdn nicht mehr, die ich meine...sry)

Wie wäre es denn, wenn Sascha selbst mal schnell den Code umbauen würde? Er sieht ja dann gleich, ob es dann klappt oder nicht.
Oder er nimmt alternativ die Deklaration des Default namespace heraus, dann müsste es eigentlich auch funktionieren.

Auch wenn es arrogant klingt: aber ich schließe aus, dass ich mich (in diesem Fall) irre.

Denn ich habe mit diesem "Fehler" auch schon genügend zu kämpfen gehabt. Sobald man dem Parser allerdings ein wenig "Nachhilfe" gibt, kommt er gut damit zurecht.

Gruß

Zitat:

However, using default namespaces instead of utilizing explicitly mapped prefixes for element names can be confusing because it is not obvious that the elements in the document are namespace scoped.

Wenn das stimmt, dann platzt mir der Arsch

*sorry*

Aber dadurch sehe ich ein klitzekleines Lichtlein am Ende des Tunnels und werde das gleich mal ausprobieren

**Neuromancer**

Ich habe nochmal gesucht, und das hier gefunden:

Zitat von msdn:

However, XPath treats the empty prefix as the null namespace. In other words, only prefixes mapped to namespaces can be used in XPath queries. If you want to use the default namespace from an XML document in the XPath expression, then you need to define a prefix for it.

Ist zwar immer noch nicht das, was ich gemeint habe, aber ich hoffe, das bringt uns weiter...

Ich suche aber nochmal...

Gruß

**marabu**

Hallo Armin,

mag sein, dass der MSXML Parser das eine oder andere Problem hat - aber an der Stelle habe ich für diesen thread nie graben müssen, denn meine Demo-Anwendung verarbeitet die Daten von Sascha problemlos. Egal ob ich XPath verwende oder direkt über documentElement.firstChild() gehe.

zusammenfalten · markieren

Delphi-Quellcode:

			procedure TDemoForm.FileOpenAccept(Sender: TObject);

var

  n: IXMLDOMNode;

begin

  with Sender as TFileOpen do

  begin

    doc := CoDomDocument.Create;

    doc.async := false;

    if doc.Load(Dialog.FileName) then

    begin

      StatusBar.SimpleText := Dialog.FileName;

      TreeNodes.Clear;

      n := doc.selectSingleNode('/kml/Document');

//    n := doc.documentElement.firstChild;

      ShowFolder(n as IXMLDOMElement, nil);

    end;

  end;

end;

Nachdenkliche Grüße vom marabu

**Neuromancer**

Hallo Marabu,

ich sehe, unsere Definitionen der Variablen gehen auseinander...

Ich erzeuge für gewöhnlich das IXMLDOMDocument mit CoDomDocument40.Create.
Die Dokument-Variable ist dabei vom Typ "IXMLDOMDocument" oder "IXMLDOMDocument2".

Könntest du das mal bitte umschreiben und dann mit XPath testen? Möglicherweise ist dieser Bug / dieses Feature neu.

Danke und Gruß

**Neuromancer**

So, ich habe es endlich gefunden...

Zitat von msdn:

One other XPath enhancement that you can expect sometime soon has to do with proper namespace support. According to the XPath specification, when expressions contain unqualified element names (no namespace prefix), the elements are considered part of no namespace (even if a default namespace declaration is present in the source document). When XPath expressions contain qualified names (through a namespace prefix) they are evaluated according to the namespace bindings that make up the current XPath context. However, there is currently no mechanism in place for establishing namespace bindings prior to evaluating an XPath expression in MSXML 3.0. This makes it impossible to properly query namespace-aware XML documents.
For example, assuming the following XML document:

<foo xmlns='urn:foo-bar:baz'>
<bar><baz/></bar>
</foo>

what should be returned by the /foo/bar/baz expression? According to the XPath specification, it should return nothing because it's looking for foo, bar, and baz elements that belong to no namespace. But in the source document the foo, bar, and baz elements all belong to the urn:foo-bar:baz namespace.
To solve this problem, in a future release of MSXML 3.0 it will be possible to specify namespace bindings through the SelectionNamespaces property before calling selectNodes, as shown here:

doc.setProperty "SelectionNamespaces", _
"xmlns:f='urn:foo-bar:baz'"
set sel = doc.selectNodes("/f:foo/f:bar/f:baz")

With the namespace bindings in place, this expression should now behave properly because it identifies foo, bar, and baz elements that belong to the 'urn:foo-bar:baz', which matches the default namespace declaration in the source document. (Note that syntax may change by release time.)

In der Praxis ergibt sich daraus folgendes:

Ich habe Saschas xml-Datei mal so "validiert":

zusammenfalten · markieren

XML-Code:

			<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://earth.google.com/kml/2.0">

   <Document>

      <Folder>

         <name>My Places</name>

         <open>1</open>

         <Folder>

            <name>Ordner1</name>

            <open>1</open>

            <Placemark>

               <name>Placemark1</name>

               <LookAt>

                  <longitude>10.37993318693747</longitude>

                  <latitude>19.35357660723419</latitude>

                  <range>743945.2733547823</range>

                  <tilt>-1.858292979523515e-013</tilt>

                  <heading>1.206473994247129</heading>

               </LookAt>

               <styleUrl>root://styleMaps#default+nicon=0x307+h

icon=0x317</styleUrl>

               <Point>

                  <coordinates>10.37993318693747,19.35357660723419

,0</coordinates>

               </Point>

            </Placemark>

         </Folder>

      </Folder>

   </Document>

</kml>

Dann funktioniert folgender Code nicht:

zusammenfalten · markieren

Delphi-Quellcode:

			procedure TForm1.btnGoClick(Sender: TObject);

var

  aXMLDoc: IXMLDOMDocument2;

  aXMLNode: IXMLDOMNode;

begin

  aXMLDoc := CoDOMDocument40.Create;

  aXMLDoc.setProperty('NewParser', true);

  aXMLDoc.setProperty('SelectionLanguage', 'XPath');

  if not aXMLDoc.loadXML(me1.Text) then

    raise Exception.Create('shyce war''s beim Laden des XML-Dokuments!');

  aXMLDoc.save('test.xml');

  aXMLNode := aXMLDoc.selectSingleNode('kml');

  if aXMLNode = nil then

     raise Exception.Create('kein Knoten gefunden!');

  ShowMessage(aXMLNode.xml);

end;

...und die Exception wird geworfen.

Bringe ich dem Parser aber bei, was M$ fordert, dann funktioniert der Code:

zusammenfalten · markieren

Delphi-Quellcode:

			procedure TForm1.btnGoClick(Sender: TObject);

var

  aXMLDoc: IXMLDOMDocument2;

  aXMLNode: IXMLDOMNode;

begin

  aXMLDoc := CoDOMDocument40.Create;

  aXMLDoc.setProperty('NewParser', true);

  aXMLDoc.setProperty('SelectionLanguage', 'XPath');

  // !!!

  aXMLDoc.setProperty('SelectionNamespaces', 'xmlns:DNS="http://earth.google.com/kml/2.0"');

  if not aXMLDoc.loadXML(me1.Text) then

    raise Exception.Create('shyce war''s beim Laden des XML-Dokuments!');

  aXMLDoc.save('test.xml');

  aXMLNode := aXMLDoc.selectSingleNode('DNS:kml'); // !!!

  if aXMLNode = nil then

     raise Exception.Create('kein Knoten gefunden!');

  ShowMessage(aXMLNode.xml);

end;

Ich hoffe, ich habe jetzt nicht noch mehr Verwirrung, sondern Aufklärung gestiftet...

Gruß

**Neuromancer**

Also, eben nachgeprüft:

Matthias und Marabu, dass euer Code funktioniert, liegt daran, dass ihr das Objekt mit CoDOMDocument.Create erzeugt. Mit dem "alten" Parser funktioniert das und man kann - wie Matthias treffend formulierte - auf den ganzen SelectionNamespaces-Quatsch verzichten.

Arbeitet man jedoch mit einer höheren Version (ich weiß jetzt nicht genau, ab welcher), dann funktioniert der Code nicht mehr.

Sascha und ich haben mit CoDOMDocument40.Create erzeugt. Dann muss der Parser über die Default Namespaces in Kenntnis gesetzt und die XPath-Query entsprechend manipuliert werden.

Ich hoffe, das Problem ist damit (endlich) aus der Welt...

Gruß

Hey, das funktioniert ja super

*freu*

Oh menno, wie zwei so kleine Zahlen doch so viel verändern können

Jetzt nur noch ein paar Kleinigkeiten *hoff* anpassen, und alles ist lecker - danke Euch

Ich denke, dass das Problem ggf. noch andere Leute treffen kann, die ebenfalls den aktuellen Parser benutzen - vielleicht sollte man das Ganze daher in die Code-Bibliothek aufnehmen.

Wenn das Progrämmchen mal fertig ist, werdet Ihr unter den Credits erwähnt - ohne Euch hätte ich es nicht geschafft!!!

**marabu**

Hallo Armin,

das hast du schön heraus gearbeitet - Danke dafür. Das Verhalten war von Microsoft bereits in den Help Files zu MSXML 3.0 dokumentiert und für eine spätere Version (4.0) angekündigt worden. Ich war bisher nur ein einziges mal drüber gestolpert - heute war das zweite und hoffentlich letzte Mal.

Freundliche Grüße

marabu