Dies ist etwas, das ich anderen immer schwer erklären kann: Warum gibt es XML-Namespaces? Wann sollten wir sie verwenden und wann nicht? Was sind die häufigsten Fallstricke bei der Arbeit mit Namespaces in XML?
Wie hängen sie auch mit XML-Schemas zusammen? Sollten XSD-Schemas immer einem Namespace zugeordnet werden?
Antworten:
Sie ermöglichen das Kombinieren mehrerer Auszeichnungssprachen, ohne sich um Konflikte zwischen Element- und Attributnamen sorgen zu müssen.
Schauen Sie sich beispielsweise einen Teil des XSLT-Codes an und überlegen Sie, was passieren würde, wenn Sie keine Namespaces verwenden und versuchen würden, ein XSLT zu schreiben, in dem die Ausgabe Elemente "template", "for-each" usw. enthalten muss . Syntaxfehler ist was.
Ich überlasse die Ratschläge und Fallstricke anderen mit mehr Erfahrung als ich.
Warum gibt es XML-Namespaces?
Denn 1997 wollten einige sehr einflussreiche Personen im W3C sie und wollten kein Nein als Antwort nehmen. Selbst als es demonstriert wurde, wage ich abschließend zu sagen, dass es bessere Möglichkeiten gab, das "Problem" zu lösen, von dem sie dachten, dass sie es hatten, sie übten ihren Einfluss aus, um ihre Wünsche in eine W3C-Empfehlung eintragen zu lassen.
Das größte Problem in der mittlerweile umfangreichen Mythologie rund um XML-Namespaces ist, dass sie technische Vorteile haben. (Dies ist der nachgelagerte Effekt einer Empfehlung, die einfach existiert und somit den Mindspace einnimmt - "gee, es muss einen (guten) Grund geben!" - im Gegensatz zu einer vergesslichen Fußnote irgendwo.)
Wann sollten wir sie verwenden und wann nicht?
Sie sollten sie niemals verwenden, wenn Sie helfen können. Leider hat die unermüdliche Werbung für dieses BAD [*] -Gerät durch interessierte Parteien zu einer Vielzahl von Spezifikationen geführt, die es praktisch unmöglich machen, sich irgendwann nicht mehr mit XML-Namespaces herumschlagen zu müssen. Selbst wenn Sie XML-Namespaces selbst meiden, werden Sie mit Namespaces verkrustete Rohstoffe aus allen Richtungen oder, schlimmer noch, Toolsets finden, die sich einfach weigern zu funktionieren, es sei denn, Sie füttern sie mit solchen Rohstoffen.
Was sind die häufigsten Fallstricke bei der Arbeit mit Namespaces in XML?
Eine sehr häufige Gefahr besteht darin, Xpath-Ausdrücke mit Dokumenten zu verwenden, in denen ein Namespace "voreingestellt" wurde: Der Namespace muss in den Ausdrücken explizit sein. Ein weiteres Problem besteht darin, sie beim Erstellen von Dokumenten "richtig" zu verwenden: Sie verursachen Probleme aus dem Nichts .
Wie hängen sie auch mit XML-Schemas zusammen? Sollten XSD-Schemas immer einem Namespace zugeordnet werden?
Es gibt keine notwendige Beziehung, außer dass die XSD-Schemaspezifikation zu einer Zeit entwickelt wurde, als fast jeder im Ausschuss die XML-Namespaces in den Zähnen hatte. Also haben sie so tief wie möglich daran gearbeitet. Es ist dennoch möglich, XSD-Schemas ohne Namespaces zu verwenden, aber es ist ein steiler Anstieg, da nahezu jedes Toolset, das XSD-Schemas unterstützt, davon ausgeht, dass Sie Namespaces verwenden möchten.
[*] BAD = Broken As Designed
UPDATE: Ein alter Aufsatz über diese Nichtlösung eines Nichtproblems .
Es ist fast das Gleiche wie die Frage "Warum verwenden wir Pakete für Java / C #?":
Die größte Gefahr ist meiner Meinung nach die Interpretation von Dokumenten durch menschliche Interaktion, z. B. um Code für die Verarbeitung eines XML-Dokuments zu entwickeln. Es ist zu einfach, sich auf den wörtlichen Ausdruck des Dokuments zu konzentrieren, als auf das Infoset-Ergebnis des Parsens des Dokuments.
zB die folgenden Knoten
<a xmlns="uri:foo"/>
<foo:a xmlns:foo="uri:foo"/>
<bar:a xmlns:bar="uri:foo"/>
sind alle semantisch identisch - und doch sehr unterschiedlich zum naiven Auge.
Das erste Beispiel liefert einen sehr häufigen Fehler bei der Entwicklung von XPaths - ohne die Tatsache, dass sich "a" in einem Namespace befindet - // a liefert also keine Übereinstimmungen. (oder schlimmer noch passende Knoten in einem anderen Namespace!)
Das dritte Beispiel eröffnet einen weiteren Fehler im Verständnis - dass der Präfixtext semantisch bedeutsam ist. Wenn ich Dokumente mit XPATH analysiere, kann ich jedes Präfix deklarieren, das ich für den Abgleich mag, solange es uri ist, das mit dem des Dokuments übereinstimmt.
Stellen Sie sich diese als Nachnamen für Elementtypen vor. Wenn Sie zwei Freunde haben, beide Bob genannt, und Sie über einen von ihnen sprechen, könnte jemand fragen, über welchen Bob Sie sprechen. Nur "Bob" zu sagen ist nicht sehr hilfreich, also sagst du "Bob Smith" oder "Bob Jones".
Dies gilt auch für Elementtypen. Manchmal reicht ein Kurzname nicht aus, weil verschiedene Personen denselben Namen auswählen können. Sie geben also eine URI als "Nachnamen" an, um zwischen den verschiedenen Bobs zu unterscheiden.
XML ist eine Supersprache, was bedeutet, dass es die Basis für jede XML-basierte Sprache ist (macht Sinn, oder?). Stellen Sie sich XML als einen Stift vor, der jeden Satz in jeder Sprache schreiben kann. Es hängt alles vom Verfasser ab, und vorzugsweise sollte die Sprache dem Leser bekannt sein.
Ein XML- Namespace ist im Grunde der Name der Sprache, ähnlich wie "Englisch" oder "עברית". Ich helfe dem Empfänger des XML-Dokuments, es zu analysieren und die darin enthaltenen Informationen zu extrahieren.
Nehmen wir an, ich habe eine Möbelfabrik und Sie haben ein Möbelgeschäft. Ihre Speicheranwendung und meine Versorgungsanwendung sind völlig unabhängig voneinander. Wenn sie jedoch über XML-Nachrichten kommunizieren, sollten die Nachrichten für beide Seiten verständlich und leicht zu analysieren sein
Daher müssen beide Systeme das Schema kennen , das die Sprachsyntax und die vereinbarten Einschränkungen definiert. Stellen Sie sich das Schema als Wörterbuch und Grammatiklehrbuch vor. Das Schema ist das Dokument, das beide Systeme kennen sollten, das jeder wissen muss, der den Parsing-Code in jedes System schreibt, und das die Deklaration des Namespace enthält.
Jeder Namespace wird als URI bezeichnet. In den meisten Fällen handelt es sich dabei um den Speicherort des Schemadokuments, das ihn definiert.
Natürlich benötigt nicht jedes XML-Dokument einen Namespace, insbesondere wenn es nicht zum Übertragen von Informationen an ein Remote-System verwendet wird. Zum Beispiel, wenn Sie Objekte in XML serialisieren, um sie in Ihrer Datenbank zu speichern.
Wir verwenden Namespaces, weil Leute xeep die gleichen Wörter verwenden möchten, um verschiedene Dinge in ihrem eigenen privaten Idaho zu bedeuten. Normalerweise können Sie anhand des Kontexts bestimmen, was eine Person bedeutet. In einer Personaldatenbank ist das XML Personalakten. In einer Fahrzeugregistrierungsdatenbank ist das XML Fahrzeugregistrierungsdatensätze.
Beide behalten ein Tag mit dem Namen "location" bei, aber das Tag bedeutet für jedes unterschiedliche Dinge und enthält unterschiedliche Felder.
Das ist cool: Aber was ist, wenn Sie XML von beiden in derselben Datenbank speichern müssen oder möchten? Interessanterweise, was ist, wenn beide Datenbanken XML-Chunks aus einer anderen, gemeinsamen Datenbank (z. B. einer Kontodatenbank) speichern möchten.
XML-Namespaces ordnen jedem XML-Tag einen URI zu, sodass dem Tag-Namen selbst eine URL vorangestellt ist, die Teil des Tag-Namens ist (natürlich verwenden tatsächliche XML-Dokumente eine Kurzform, um dies zu tun). Wenn Sie den URI sorgfältig auswählen, können Sie sicher sein, dass die Tag-Namen nicht kollidieren. Es ist, als ob die beiden Standort-Tags völlig unterschiedlich benannt wurden, sodass keine Verwirrung entsteht. Als Bonus können die beiden völlig unterschiedlichen Standort-Tags Inhalte aus der Kontodatenbank enthalten und explizit angeben, dass es sich um dasselbe handelt.
Das, was all dies nützlich macht, ist XPATH.
Mit dem oben Gesagten können Sie beginnen, XPATH-Ausdrücke zu schreiben, die Dinge sagen wie: Finden Sie mir accounts:account overdueirgendwo in dieser XML-Datei. Oder: Suchen Sie mir accounts:warning messageirgendwo in diesem bestimmten XML-Block Elemente, bei denen die Warnmeldung ein untergeordneter Knoten (egal wie tief) eines personnel:paymentKnotens oder eines vehicle:statusKnotens ist.
Dieser XPATH-Ausdruck kann irgendwo in einem XSLT-Dokument verwendet werden, dessen Aufgabe es ist, das XML zur Anzeige in XHTML oder XPDF zu konvertieren.
Was ist die Auszahlung? Warum? Da Sie die XML-Protokolldatei durchsuchen können, ziehen Sie alle überfälligen Kontonachrichten ab, wo immer sie angezeigt werden, ohne sie mit "Nachrichten" -Tags anderer Systeme zu verwechseln, konvertieren Sie sie in xhtml und zeigen Sie sie über ein CSS-Tag in Fettdruck an: all ohne einen Teil des Verfahrenscodes zu schreiben .
Zum Beispiel: XML-Namespaces anhand eines Beispiels
In meinen Worten: Wenn Sie beispielsweise ein XML-Format für ein externes Unternehmen verwenden müssen und im XML-Dokument einige Informationen mit demselben Namen bereitstellen müssen, benötigen Sie einen Namespace. Beispiel:
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="Blue"/>
</items>
</header>
</sampleDoc>
und Sie möchten einige Daten in diesem Dokument zusammenführen, das denselben Namen hat, aber einen anderen Sinn (also Wert für), sollten Sie einen Namespace verwenden:
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="White" my_unique_namespace:color="#FFFFFF"/>
</items>
</header>
</sampleDoc>
Natürlich - Sie können einen Attributnamen ändern. Zum Beispiel zu "my_unique_color". Bud in einem anderen Dokument kann es wieder Attribute mit dem gleichen Namen geben. Wenn Sie also einen eindeutigen Namespace haben (z. B. unsere Webdomain), können Sie jederzeit problemlos dieselben Namen von Elementen und / oder Attributen verwenden.
Aus der W3-Empfehlung ...
XML-Namespaces bieten eine einfache Methode zum Qualifizieren von Element- und Attributnamen, die in Dokumenten der Extensible Markup Language verwendet werden, indem sie Namespaces zugeordnet werden, die durch URI-Referenzen identifiziert werden.
Namespaces werden verwendet, um Namen, die Sie im Dokument verwenden, zu unterscheiden. Außerdem können Sie einen Kurznamen an einen Namensraum binden, der dann zum Verweisen auf ein entferntes Element oder Attribut verwendet werden kann. Der Namensraum selbst bezieht sich auf den Speicherort, der die Elemente und Attribute definiert, die Sie im Dokument verwenden. Es gibt noch viel mehr zu wissen, aber das ist das Herzstück davon. Es gibt viel mehr Informationen hier .