Deutsche, kommentierte Übersetzung\nDies ist die deutsche Übersetzung der W3C-Empfehlung "XML Path Language (XPath)" vom 16. November 1999. Bitte beachten Sie, dass dieses Dokument Übersetzungsfehler enthalten kann. Die normative englische Version des Dokuments befindet sich unter http://www.w3.org/TR/1999/REC-xpath-19991116\nOliver Becker <ob@obqo.de>\nDieses Dokument ist urheberrechtlich geschützt, Copyright © 1999–2002 W3C® (MIT, INRIA, Keio), alle Rechte vorbehalten. Die Rechte an dieser Übersetzung liegen beim Übersetzer, Copyright © 2002 Oliver Becker.\nCopyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. Es gelten die W3C-Regeln zu Haftung, Warenzeichen und Verwendung des Dokuments sowie die Lizenzregeln für Software.\nDie Sprache XPath dient zur Adressierung von Teilen eines XML-Dokuments. Sie wurde für die Verwendung sowohl in XSLT als auch in XPointer entworfen.\nDieses Dokument wurde von Mitgliedern des W3C und anderen Interessierten geprüft und vom Direktor als W3C-Empfehlung gebilligt. Es ist ein abgeschlossenes Dokument und darf als Referenzmaterial verwendet oder als normative Referenz von einem anderen Dokument zitiert werden. Die Rolle des W3C bei der Erstellung dieser Empfehlung ist es, die Spezifikation bekannt zu machen und ihre breite Anwendung zu fördern. Dies erhöht die Funktionsfähigkeit und Interoperabilität des Web.\nDie Liste der bekannten Fehler in dieser Spezifikation ist unter http://www.w3.org/1999/11/REC-xpath-19991116-errata verfügbar.\nAnmerkungen zu dieser Spezifikation können an www-xpath-comments@w3.org geschickt werden; alle Anmerkungen sind in einem Archiv verfügbar.\nDie englische Version dieser Spezifikation ist die einzig normative Version. Allerdings werden Übersetzungen dieses Dokuments unter http://www.w3.org/Style/XSL/translations.html aufgeführt.\nAktuelle W3C-Empfehlungen und weitere technische Dokumente sind unter http://www.w3.org/TR zu finden.\nDiese Spezifikation ist das Ergebnis der gemeinsamen Arbeit der XSL- und der XML-Linking-Arbeitsgruppen und damit Teil der W3C Style Activity und der W3C XML Activity.\nXPath ist das Ergebnis der Bemühungen, eine gemeinsame Syntax und Semantik für jene Funktionen bereitzustellen, die sowohl von XSL Transformations [XSLT] als auch von XPointer [XPointer] genutzt werden. Die primäre Aufgabe von XPath besteht in der Adressierung von Teilen eines XML-Dokuments [XML]. Zur Unterstützung dieser Aufgabe werden außerdem einfache Hilfsmittel für die Manipulation von Zeichenketten, Zahlen und booleschen Werten bereitgestellt. XPath benutzt eine kompakte Nicht-XML-Syntax, um die Verwendung von XPath-Ausdrücken innerhalb von URIs und XML-Attributen zu erleichtern. XPath operiert auf der abstrakten, logischen Struktur eines XML-Dokuments, nicht auf seiner äußerlichen Syntax. Seinen Namen erhält XPath durch die Verwendung einer auch in URLs genutzten Pfad-Notation (path), mit der sich durch die hierarchische Struktur eines XML-Dokuments navigieren lässt.\nNeben der Verwendung für die Adressierung wurde XPath so gestaltet, dass eine natürliche Teilmenge davon zum Matching (Testen, ob ein Knoten auf ein Muster passt) genutzt werden kann. Diese Anwendung von XPath ist in XSLT beschrieben.\nNeben XSLT und XPointer existieren weitere Spezifikationen, die XPath nutzen. Als Beispiel sei hier der Arbeitsentwurf des W3C für die XML-Abfragesprache XQuery [XQuery] genannt, deren Syntax erweiterte XPath-Ausdrücke verwendet.\nXPath modelliert ein XML-Dokument als einen Baum, der aus Knoten besteht. Es gibt verschiedene Knotentypen, unter anderem Elementknoten, Attributknoten und Textknoten. XPath definiert, wie der Zeichenkettenwert für jeden Knotentyp berechnet wird. Einige Knoten besitzen zusätzlich einen Namen. XPath unterstützt in vollem Umfang XML-Namensräume [XML Names]. Daher wird der Name eines Knotens als ein Paar aus einem lokalen Bestandteil und einem gegebenenfalls leeren Namensraum-URI modelliert – dieses wird erweiterter Name genannt. Das Datenmodell ist detailliert in [5 Datenmodell] beschrieben.\nZur Veranschaulichung der durch XPath modellierten Baumstruktur soll folgendes Beispiel dienen:\n<!DOCTYPE rezept SYSTEM "rezept.dtd">\n<?xml-stylesheet href="style.xsl" type="text/xml"?>\n<zutat id="mehl">200g Mehl</zutat>\n<!-- weitere Zutaten -->\nDie XML-Deklaration sowie die Dokumenttyp-Deklaration finden sich in der Baumdarstellung nicht wieder, auf sie kann über einen XPath-Ausdruck auch nicht zugegriffen werden. Alle anderen Bestandteile des Dokuments (Wurzel, Elemente, Textinhalt, Attribute, Namensräume, Kommentare, Processing Instructions) werden durch entsprechende Knoten des Baumes repräsentiert. Die leeren Quadrate symbolisieren Textknoten, die ausschließlich Leerraumzeichen enthalten. Inwieweit sich solcher Leerraum in eigenen Textknoten wiederfindet, wird von der XPath nutzenden Anwendung bestimmt. Schließlich sei auf die implizit zu jedem Element gehörenden Namensraumknoten für den xml-Namensraum hingewiesen.\nDas Document Object Model [DOM] definiert ebenfalls eine Baumrepräsentation, die allerdings in einigen Punkten von der in XPath verwendeten abweicht. Auf diese Unterschiede wird innerhalb des Kapitels [5 Datenmodell] eingegangen.\nDas primäre syntaktische Konstrukt in XPath ist der Ausdruck. Ein Ausdruck lässt sich aus der Produktion Expr ableiten. Die Auswertung eines Ausdrucks ergibt ein Objekt, das zu einem der folgenden vier Grundtypen gehört:\nnode-set (eine ungeordnete Menge von Knoten ohne Duplikate)\nDas sind die vier Grundtypen, die XPath definiert. Tatsächlich können darauf aufbauende Spezifikationen weitere Typen definieren, sodass die Auswertung eines XPath-Ausdrucks ein Objekt dieses neuen Typs ergeben kann. Insbesondere können im Ausdruck enthaltene Variablen Objekte anderer Typen aufnehmen.\nWie man sieht, gibt es keinen Datentyp für Knoten. Ein einzelner Knoten kann aber als Knotenmenge (node-set) dargestellt werden, die genau ein Element enthält.\nEin Ausdruck wird immer bezüglich eines Kontextes ausgewertet. XSLT und XPointer spezifizieren, wie dieser Kontext bei der Verwendung von XPath-Ausdrücken in XSLT bzw. XPointer bestimmt wird. Der Kontext besteht aus:\nden Namensraumdeklarationen, in deren Gültigkeitsbereich der Ausdruck liegt\nDie Kontextposition ist immer kleiner oder gleich der Kontextgröße.\nDie Variablenbelegungen bestehen aus einer Abbildung von Variablennamen auf Variablenwerte. Der Wert einer Variablen ist ein Objekt, welches von jedem beliebigen Typ sein kann, der für Ausdrücke möglich ist. Daneben sind auch weitere Typen möglich, die hier nicht spezifiziert werden.\nIn der XSLT-1.0-Spezifikation [XSLT] wird beispielsweise als neuer Typ Ergebnisteilbaum (result tree fragment) eingeführt. Werte dieses Typs entstehen im Ergebnis des Transformationsprozesses. Durch die folgende Variablenvereinbarung wird z.B. eine Variable namens antwort erzeugt, deren Wert ein Ergebnisteilbaum ist:\n<antwort><xsl:value-of select="6 * 7" /></antwort>\nDieser Typ wird voraussichtlich in zukünftigen XSLT-Versionen nicht mehr existieren, da das Ergebnis einer Transformation dann eine normale Knotenmenge vom Typ node-set sein wird, siehe [XSLT 2.0].\nDie folgende Anweisung erzeugt dagegen eine Variable, deren Wert sich aus der Berechnung eines XPath-Ausdrucks expression ergibt:\n<xsl:variable name="var" select="expression" />\nAn dieser Stelle sei darauf hingewiesen, dass die Erzeugung der Variablenbelegungen für antwort und var ein XSLT-Sprachmittel ist. XPath selbst stellt hierfür keinerlei Konstrukte bereit. Neben xsl:variable besitzt XSLT für diesen Zweck xsl:param.\nDie XPointer-Spezifikation [XPointer], die ebenfalls XPath nutzt, sieht keine Möglichkeiten für das Erzeugen von Variablenbelegungen vor. Die Verwendung von Variablenreferenzen innerhalb eines XPointer-Ausdrucks führt daher zu einem syntaktischen Fehler. Die als Arbeitsentwurf des W3C vorgelegte Abfragesprache für XML-Dokumente XQuery [XQuery] benutzt zur Erzeugung von Variablenbelegungen so genannte FLWR-Ausdrücke (gesprochen "flower", eine Abkürzung für FOR-, LET-, WHERE- und RETURN-Klauseln).\nDie Funktionsbibliothek besteht aus einer Abbildung von Funktionsnamen auf Funktionen. Jede Funktion besitzt null oder mehr Argumente und liefert einen einzelnen Wert. Diese Spezifikation definiert eine Bibliothek von Grundfunktionen, die von allen XPath-Implementationen unterstützt werden muss (siehe [4 Bibliothek der Grundfunktionen]). Bei einer Grundfunktion gehören die Argumente und das Ergebnis einem der vier Grundtypen an. Sowohl XSLT als auch XPointer erweitern XPath um zusätzliche Funktionen, von denen einige auf den vier Grundtypen, andere auf zusätzlichen, durch XSLT und XPointer definierten Typen operieren.\nNamensraumdeklarationen bestehen aus einer Abbildung von Präfixen auf Namensraum-URIs.\nAngenommen, ein Element enthält in seinem Start-Tag folgende Namensraumdeklaration: xmlns:xlink="http://www.w3.org/1999/xlink". Ein Kontext, für den diese Deklaration gültig ist, enthält dann eine Abbildung des Präfixes xlink auf den URI http://www.w3.org/1999/xlink.\nDie Variablenbelegungen, die Funktionsbibliothek und die Namensraumdeklarationen, die benutzt werden, um einen Teilausdruck zu berechnen, sind immer dieselben, die auch für den umgebenden Ausdruck benutzt werden. Der Kontextknoten, die Kontextposition und die Kontextgröße, die zur Berechnung eines Teilausdrucks benutzt werden, sind dagegen zuweilen verschieden von denen des umgebenden Ausdrucks. Mehrere Arten von Ausdrücken ändern den Kontextknoten, aber nur Prädikate ändern die Kontextposition und die Kontextgröße (siehe [2.4 Prädikate]). Bei der Beschreibung, wie bestimmte Ausdrücke zu berechnen sind, wird immer explizit angegeben, ob sich der Kontextknoten, die Kontextposition oder die Kontextgröße bei der Berechnung von Teilausdrücken ändert. Wird nichts über Kontextknoten, Kontextposition und Kontextgröße ausgesagt, bleiben sie bei der Berechnung von Teilausdrücken dieser Ausdrücke gleich.\nInnerhalb eines Lokalisierungspfades ändert jeder Schritt den Kontextknoten, der für die Berechnung der folgenden Schritte relevant ist. Durch ein Prädikat werden Knoten aus einer Knotenmenge herausgefiltert, sodass die Kontextgröße sich in der Regel verkleinert und die Position der gefilterten Knoten sich entsprechend ändert.\nXPath-Ausdrücke erscheinen häufig in XML-Attributen. Die in diesem Abschnitt spezifizierte Grammatik wird auf Attributwerte nach ihrer Normalisierung gemäß XML 1.0 angewendet. Wenn beispielsweise die Grammatik das Zeichen < verwendet, darf dieses nicht in der XML-Quelle als < auftreten, sondern muss gemäß den XML-1.0-Regeln notiert werden, zum Beispiel durch Eingabe als <. Innerhalb von Ausdrücken werden Zeichenkettenliterale durch einfache oder doppelte Anführungszeichen begrenzt, die ebenfalls zur Begrenzung von XML-Attributen verwendet werden. Um zu vermeiden, dass ein Anführungszeichen innerhalb eines Ausdrucks durch den XML-Prozessor als Abschluss des Attributwertes interpretiert wird, kann das Anführungszeichen als Zeichenreferenz eingegeben werden (" oder '). Alternativ können im Ausdruck einfache Anführungszeichen benutzt werden, falls das XML-Attribut durch doppelte Anführungszeichen begrenzt wird oder umgekehrt.\nAbgesehen davon gibt es immer noch Fälle, in denen dieses einfache Kochrezept nicht ausreichend ist – nämlich dann, wenn eine Zeichenkette benötigt wird, die beide Arten von Anführungszeichen enthalten soll.\npara="Sie fragte: "Wie geht's?""\nDas ist aber keine Lösung, da ein XML-Parser, der diese Zeichenfolge analysiert, Entity-Referenzen auflöst. Ein darauf aufsetzender XPath-Prozessor kann nicht mehr zwischen »"« und »"« unterscheiden. Formuliert man im nächsten Schritt dann nämlich weiter\n<xsl:if test='para="Sie fragte: "Wie geht's?""'>\n(diese Zeile ist im XML-Sinn wohlgeformt), so führt das zu einem Fehler im XPath-Prozessor, da dieser trotzdem die folgende Zeichenkette auswertet:\nEine einfache Lösung für solche Fälle besteht darin, die betreffende Zeichenkette als Wert einer Variablen zu definieren, etwa in XSLT per\n<xsl:variable name="string">Sie fragte: "Wie geht's?"</xsl:variable>\nund anschließend diese Variable in XPath-Ausdrücken zu verwenden.\nAlternativ kann man die gewünschte Zeichenkette aus mehreren Teilen zusammensetzen (unter Benutzung der noch zu erläuternden Funktion concat), wobei jede Teilzeichenkette jeweils nur eine Sorte von Anführungszeichen enthält:\nDas Anführungszeichen, das zur Begrenzung dieses Ausdrucks innerhalb eines Attributwertes genutzt wird, muss dann durch die dazugehörige Entity-Referenz ersetzt werden. Das Ergebnis sieht zwar unübersichtlich aus, ist aber syntaktisch korrekt:\n<xsl:if test="para=concat('Sie fragte: "Wie geht',\nEin wichtiger spezieller Ausdruck ist der Lokalisierungspfad. Ein Lokalisierungspfad wählt eine Knotenmenge relativ zu einem Kontextknoten aus. Das Ergebnis der Berechnung eines Ausdrucks, der ein Lokalisierungspfad ist, ist genau die Knotenmenge, die die durch den Lokalisierungspfad ausgewählten Knoten enthält. Lokalisierungspfade können Ausdrücke rekursiv enthalten, die zum Filtern von Knotenmengen benutzt werden. Ein Lokalisierungspfad lässt sich aus der Produktion LocationPath ableiten.\nDie in der nachfolgenden Grammatik verwendeten Nichtterminale QName und NCName sind in [XML Names] definiert, S ist in [XML] definiert. Die Grammatik verwendet die gleiche EBNF-Notation wie in [XML] (mit der Ausnahme, dass Grammatiksymbole immer mit einem Großbuchstaben beginnen).\nDie Erweiterte Backus-Naur-Form (EBNF) wird zur Notation von formalen Grammatiken verwendet. Sie wird im Kapitel Notation der XML-Spezifikation [XML, 2nd Edition] näher erläutert.\nAusdrücke werden geparst, indem die Zeichenfolge in einzelne Tokens zerlegt und anschließend die entstehende Folge der Tokens geparst wird. Leerraumzeichen können beliebig zwischen Tokens verwendet werden. Der Zerlegungsprozess wird in [3.7 Lexikalische Struktur] beschrieben.\nEin Token ist eine syntaktische Einheit von Zeichen, etwa der Name »html«, die Zahl »3.14159« oder der Operator »!=«. Die zwischen diesen Tokens erlaubten Leerraumzeichen sind gemäß der XML-Spezifikation Folgen aus Leerzeichen (#x20), Tabulatoren (#x9), Zeilenvorschüben (#xA) und Wagenrückläufen (#xD). Innerhalb eines Tokens dürfen keine solchen Leerraumzeichen auftreten, so z.B. nicht zwischen den beiden einzelnen Zeichen »!« und »=« des Operators »!=«.\nObwohl Lokalisierungspfade nicht das allgemeinste grammatische Konstrukt der Sprache darstellen (ein Lokalisierungspfad ist ein Spezialfall eines Ausdrucks), sind sie doch das wichtigste Konstrukt und werden deshalb als Erstes beschrieben.\nJeder Lokalisierungspfad kann durch eine unkomplizierte und eher verbale Syntax ausgedrückt werden. Daneben gibt es eine Reihe von syntaktischen Abkürzungen, mit denen sich häufige Fälle kurz und prägnant ausdrücken lassen. Dieser Abschnitt erläutert die Semantik von Lokalisierungspfaden anhand der ausführlichen Syntax. Die abgekürzte Syntax wird im Anschluss daran erläutert, indem gezeigt wird, wie diese auf die ausführliche Syntax abgebildet wird (siehe [2.5 Abgekürzte Syntax]).\nEs folgen einige Beispiele für Lokalisierungspfade unter Benutzung der ausführlichen Syntax:\nchild::para wählt die Kindelemente para des Kontextknotens aus.\nchild::text() wählt alle Textknoten aus, die Kinder des Kontextknotens sind.\nchild::node() wählt alle Kindknoten des Kontextknotens aus, unabhängig von ihrem Knotentyp.\nObwohl sich sämtliche XPath-Lokalisierungspfade für Kontextknoten jedes Typs anwenden lassen, muss an dieser Stelle darauf hingewiesen werden, dass nur der Wurzelknoten sowie Elementknoten Kinder haben können. Diese Kinder können Element-, Text-, Kommentar- und Processing-Instruction-Knoten sein. Attribut- und Namensraumknoten sind niemals Kinder anderer Knoten. Dieses Konzept wird noch einmal ausführlich in Kapitel [5 Datenmodell] beschrieben.\nattribute::name wählt das Attribut name des Kontextknotens aus.\nattribute::* wählt alle Attribute des Kontextknotens aus.\ndescendant::para wählt die para-Elemente aus, die Nachkommen des Kontextknotens sind.\nancestor-or-self::div wählt alle div-Vorfahren des Kontextknotens sowie auch den Kontextknoten selbst aus, falls dieser ein div-Element ist.\ndescendant-or-self::para wählt alle para-Nachkommen des Kontextknotens aus, sowie auch den Kontextknoten selbst, falls dieser ein para-Element ist.\nchild::chapter/descendant::para wählt die para-Elemente aus, die Nachkommen der chapter-Kindelemente des Kontextknotens sind.\n/ wählt die Wurzel des Dokuments aus (diese ist immer der Vater des Dokumentelements).\nDer Begriff Wurzel unterscheidet sich hier von dem in der XML-Spezifikation [XML, 2nd Edition] genutzten. Dort bezeichnen Wurzel und Dokumentelement das Gleiche. In der XPath-Terminologie ist das Dokumentelement ein Kind des Wurzelknotens. Der Wurzelknoten entspricht damit dem Dokument-Entity, siehe [5.1 Wurzelknoten]. Das ist insofern wichtig, als der Wurzelknoten zusätzlich Kommentar- oder Processing-Instruction-Knoten als Kinder haben kann, die damit Geschwister des Dokumentelements sind.\nDes Weiteren muss hier hinzugefügt werden, dass durch / die Wurzel des Dokuments ausgewählt wird, in dem sich der Kontextknoten befindet. Es lässt sich leicht eine Knotenmenge bilden, die Knoten aus verschiedenen Dokumenten enthält. Die in XSLT definierte Funktion document liefert beispielsweise den Wurzelknoten eines anderen Dokuments.\n/descendant::para wählt alle para-Elemente aus, die im gleichen Dokument wie der Kontextknoten enthalten sind.\n/descendant::olist/child::item wählt alle item-Elemente aus, die ein olist-Vaterelement besitzen und die sich im gleichen Dokument wie der Kontextknoten befinden.\nDie folgenden Beispiele zeigen Lokalisierungspfade, bei denen die ursprünglich ausgewählten Knotenmengen durch nachgestellte Filterausdrücke in eckigen Klammern, so genannte Prädikate, weiter eingeschränkt werden.\nchild::para[position()=1] wählt das erste para-Kindelement des Kontextknotens aus.\nchild::para[position()=last()] wählt das letzte para-Kindelement des Kontextknotens aus.\nchild::para[position()=last()-1] wählt das vorletzte para-Kindelement des Kontextknotens aus.\nchild::para[position()>1] wählt alle para-Kindelemente des Kontextknotens aus, mit Ausnahme des ersten para-Kindelements des Kontextknotens.\nfollowing-sibling::chapter[position()=1] wählt das nächste chapter-Geschwisterelement des Kontextknotens aus.\npreceding-sibling::chapter[position()=1] wählt das vorhergehende chapter-Geschwisterelement des Kontextknotens aus.\nAn dieser Stelle sei als kurzer Vorgriff darauf hingewiesen, dass sich die Position eines Knotens in der aktuellen Kontextknotenliste über die Funktion position bestimmen lässt und diese Position offenbar von der Blickrichtung abhängt. Von allen vorhergehenden Geschwisterelementen befindet sich der unmittelbare Vorgänger an der Position 1.\n/descendant::figure[position()=42] wählt das zweiundvierzigste figure-Element im Dokument aus.\n/child::doc/child::chapter[position()=5]/child::section[position()=2] wählt das zweite section-Element des fünften chapter-Elements des doc-Dokumentelements aus.\nchild::para[attribute::type="warning"] wählt alle para-Kindelemente des Kontextknotens aus, die ein type-Attribut mit dem Wert warning besitzen.\nchild::para[attribute::type='warning'][position()=5] wählt das fünfte para-Kindelement des Kontextknotens aus, das ein Attribut type mit dem Wert warning besitzt.\nchild::para[position()=5][attribute::type="warning"] wählt das fünfte para-Kindelement des Kontextknotens aus, wenn dieses Kind ein type-Attribut mit dem Wert warning besitzt.\nDie letzten beiden Beispiele zeigen, wie sich durch ein Prädikat Kontextgröße und -position ändern können. Das Prädikat [position()=5] liefert immer eine Knotenmenge, die maximal einen Knoten enthält, je nachdem, ob es einen fünften Knoten gibt oder nicht. Das erste der beiden Beispiele beschränkt zunächst die betrachtete Knotenmenge auf die para-Elemente mit dem Attribut type="warning" und wählt anschließend aus diesen das fünfte aus. Das zweite Beispiel wählt zuerst das fünfte para-Element und anschließend aus der verbleibenden Knotenmenge die Knoten mit dem gewünschten Attribut aus. Besitzt das fünfte para-Element also gerade kein Attribut type="warning", so ist das Ergebnis in diesem Fall die leere Knotenmenge.\nchild::chapter[child::title='Introduction'] wählt die chapter-Kindelemente des Kontextknotens aus, die wenigstens ein title-Kindelement mit einem Zeichenkettenwert gleich Introduction besitzen.\nchild::chapter[child::title] wählt die chapter-Kindelemente des Kontextknotens aus, die ein oder mehrere title-Kindelemente besitzen.\nchild::*[self::chapter or self::appendix] wählt die chapter- und appendix-Kindelemente des Kontextknotens aus.\nHier werden aus allen Kindern (child::*) diejenigen ausgewählt, die selbst (self::) entweder ein chapter- oder ein appendix-Element sind. Hier muss man etwas aufpassen, da der Ausdruck in den eckigen Klammern für einen anderen Kontextknoten ausgewertet wird als der Ausdruck vor den Klammern. Der Vergleich mit den beiden vorhergehenden Beispielen verdeutlicht den Unterschied. Die genaue Definition folgt in Kapitel [2.4 Prädikate].\nchild::*[self::chapter or self::appendix][position()=last()] wählt das letzte chapter- oder appendix-Kindelement des Kontextknotens aus.\nEs gibt zwei Arten von Lokalisierungspfaden: relative und absolute Lokalisierungspfade.\nEin relativer Lokalisierungspfad wird durch eine Folge aus einem oder mehreren Lokalisierungsschritten gebildet, die durch / voneinander getrennt sind. Die Schritte eines relativen Lokalisierungspfades werden von links nach rechts zusammengesetzt. Jeder Schritt wählt der Reihe nach eine Knotenmenge relativ zu einem Kontextknoten aus. Eine Anfangsfolge von Schritten wird mit einem folgenden Schritt wie folgt zusammengesetzt: Die Anfangsfolge von Schritten wählt eine Knotenmenge relativ zu einem Kontextknoten aus. Jeder Knoten in dieser Menge wird dann als Kontextknoten für den folgenden Schritt benutzt. Die durch diesen Schritt bestimmten Knotenmengen werden vereinigt. Die Vereinigung ist dann genau die Knotenmenge, die durch das Zusammensetzen der Schritte ausgewählt wird. Zum Beispiel wählt child::div/child::para die para-Kindelemente der div-Kindelemente des Kontextknotens aus, oder – mit anderen Worten – die para-Enkelelemente, die div-Elternelemente haben.\nEin absoluter Lokalisierungspfad besteht aus dem Zeichen / und einem optional folgenden relativen Lokalisierungspfad. Ein / allein wählt den Wurzelknoten des Dokuments aus, das den Kontextknoten enthält. Falls ein relativer Lokalisierungspfad folgt, so wählt der Lokalisierungspfad die Knotenmenge aus, die ein relativer Lokalisierungspfad relativ zum Wurzelknoten des den Kontextknoten enthaltenen Dokuments auswählen würde.\nHier bietet sich der Vergleich zu Pfaden im Dateisystem an: Sowohl in UNIX-Betriebssystemen als auch innerhalb von URLs wird der Schrägstrich »/« als Trennzeichen innerhalb von Dateipfaden benutzt. In ähnlicher Weise kann man sich Pfade in einem XML-Baum vorstellen. Ein relativer Pfad geht immer vom aktuellen Knoten (dem Kontextknoten) aus, ein absoluter Pfad beginnt immer an der Dokumentwurzel. Genau genommen ist ein absoluter Pfad allerdings ebenfalls relativ, nämlich zum Dokument des Kontextknotens. Das spielt eine Rolle, wenn Knoten aus mehreren Dokumenten verarbeitet werden.\nMan sollte sich allerdings einer Feinheit bewusst sein: Während beispielsweise durch »verzeichnis1/verzeichnis2/datei3« in einem Dateisystem exakt eine Datei adressiert wird, eben jene, die den Namen »datei3« trägt und sich in dem Unterverzeichnis »verzeichnis1/verzeichnis2« befindet, wählt ein analoger XPath immer eine Knotenmenge aus, die in der Regel mehrere Knoten enthalten kann. Das sollte aber nicht weiter verwundern, darf ein Element doch durchaus mehrere gleichnamige Kindelemente besitzen.\neine Achse, welche die Beziehung zwischen den durch den Lokalisierungsschritt ausgewählten Knoten und dem Kontextknoten innerhalb des Baumes spezifiziert,\neinen Knotentest, der den Knotentyp und den erweiterten Namen der durch den Lokalisierungsschritt ausgewählten Knoten spezifiziert, sowie\nnull oder mehr Prädikate, die mittels beliebiger Ausdrücke die durch den Lokalisierungsschritt ausgewählte Knotenmenge weiter verfeinern können.\nPrädikate im mathematischen Sinn sind Aussagen über Eigenschaften, die für die betreffenden Objekte wahr oder falsch sein können. In diesem Sinn wählt ein Prädikat aus einer Knotenmenge genau diejenigen Knoten aus, für die die entsprechende Aussage zutrifft. Aber auch ohne Kenntnis der Begriffswelt der Prädikatenlogik kann man sich anhand der Begriffe »Prädikatswein« oder »Prädikatsexamen« verdeutlichen, dass hier jeweils eine bestimmte Eigenschaft bzw. Qualität des beschriebenen Objekts ausgedrückt wird.\nEin Lokalisierungsschritt besteht syntaktisch aus dem Namen der Achse, gefolgt von zwei Doppelpunkten und dem Knotentest, gefolgt von null oder mehr in eckigen Klammern eingeschlossenen Ausdrücken. Zum Beispiel enthält child::para[position()=1] die Achse child, den Knotentest para und ein Prädikat [position()=1].\nDie durch den Lokalisierungspfad ausgewählte Knotenmenge ergibt sich aus der durch Achse und Knotentest bestimmten Ausgangsknotenmenge, indem dort der Reihe nach die einzelnen Prädikate angewendet werden.\nDie Ausgangsknotenmenge enthält alle Knoten, die zum Kontextknoten in der durch die Achse angegebenen Beziehung stehen und die den im Knotentest spezifizierten Knotentyp und erweiterten Namen besitzen. Zum Beispiel wählt der Lokalisierungsschritt descendant::para alle para-Nachkommen des Kontextknotens aus: descendant besagt, dass jeder Knoten in der Ausgangsknotenmenge ein Nachkomme des Kontextknotens sein muss; para besagt, dass jeder Knoten in der Ausgangsknotenmenge ein Element mit dem Namen para sein muss. Die verfügbaren Achsen werden in [2.2 Achsen] beschrieben, die verfügbaren Knotentests in [2.3 Knotentests]. Die Bedeutung einiger Knotentests hängt von der jeweiligen Achse ab.\nDie Ausgangsknotenmenge wird durch das erste Prädikat gefiltert und ergibt eine neue Knotenmenge. Diese wird anschließend durch das zweite Prädikat gefiltert und so weiter. Die resultierende Knotenmenge ist schließlich die Knotenmenge, die durch den Lokalisierungsschritt ausgewählt wird. Die Achse beeinflusst, wie der Ausdruck in jedem Prädikat berechnet wird. Die Semantik eines Prädikats ist damit bezüglich einer Achse definiert (siehe [2.4 Prädikate]).\nZur Verdeutlichung der Vorgehensweise bei mehreren Prädikaten sei auf die beiden bereits diskutierten Beispiele\nDie Achse child enthält die Kinder des Kontextknotens.\nDie Nummern geben die Näheposition der Knoten in der durch die Achse ausgewählten Knotenmenge an.\nDie Achse descendant enthält die Nachkommen des Kontextknotens; ein Nachkomme ist ein Kind oder ein Kind eines Kindes usw. Die Nachkommenachse enthält niemals Attribut- oder Namensraumknoten.\nDie Achse parent enthält den Elternknoten des Kontextknotens, falls es einen gibt.\nDie Achse ancestor enthält die Vorfahren des Kontextknotens; die Vorfahren des Kontextknotens bestehen aus dem Elternknoten des Kontextknotens, dessen Elternknoten usw. Die Vorfahrenachse enthält somit immer den Wurzelknoten, es sei denn, der Kontextknoten selbst ist der Wurzelknoten.\nDie Achse following-sibling enthält alle nachfolgenden Geschwister des Kontextknotens; falls der Kontextknoten ein Attribut- oder Namensraumknoten ist, ist diese Achse leer.\nDie Achse preceding-sibling enthält alle vorhergehenden Geschwister des Kontextknotens; falls der Kontextknoten ein Attribut- oder Namensraumknoten ist, ist diese Achse leer.\nDie Achse following enthält alle Knoten im gleichen Dokument wie der Kontextknoten, die nach dem Kontextknoten in Dokumentordnung auftreten, und zwar ohne seine Nachkommen und ohne Attribut- und Namensraumknoten.\nDie Achse preceding enthält alle Knoten im gleichen Dokument wie der Kontextknoten, die vor dem Kontextknoten in Dokumentordnung auftreten, und zwar ohne seine Vorfahren und ohne Attribut- und Namensraumknoten.\nDie Achse attribute enthält die Attribute des Kontextknotens; diese Achse ist leer, es sei denn, der Kontextknoten ist ein Elementknoten.\nDie Achse namespace enthält alle Namensraumknoten des Kontextknotens; diese Achse ist leer, es sei denn, der Kontextknoten ist ein Elementknoten.\nDie Achse self enthält nur den Kontextknoten selbst.\nDie Achse descendant-or-self enthält den Kontextknoten sowie die Nachkommen des Kontextknotens.\nDie Achse ancestor-or-self enthält den Kontextknoten sowie die Vorfahren des Kontextknotens; diese Achse enthält somit immer den Wurzelknoten.\nAnmerkung: Die Achsen ancestor, descendant, following, preceding und self partitionieren ein Dokument (unter Auslassung der Attribut- und Namensraumknoten): sie überschneiden sich nicht und enthalten zusammen alle Knoten des Dokuments.\nAttribut- und Namensraumachse nehmen hier eine Sonderrolle ein. Die adressierten Knoten zeichnen sich nämlich durch einen bestimmten festen Knotentyp aus (den so genannten Hauptknotentyp). Da diese Knoten per Definition keine Kinder anderer Knoten sind, wurden die speziellen Achsen attribute und namespace definiert. Trotzdem kann sich auch an diese Achsen ein beliebiger Knotentest anschließen (siehe [2.3 Knotentests]). Dies birgt die Gefahr, dass zwar syntaktisch korrekte, aber sinnlose Lokalisierungsschritte benutzt werden können, die niemals einen Knoten auswählen. Der Lokalisierungsschritt attribute::text(), der über die Attributachse einen Textknoten auswählen soll, liefert beispielsweise immer eine leere Knotenmenge.\nJede Achse besitzt einen Hauptknotentyp. Falls eine Achse Elemente enthalten kann, so ist der Hauptknotentyp der Elementtyp, ansonsten ist es genau der Typ der Knoten, die die Achse enthalten kann. Das bedeutet:\nFür die Namensraumachse ist der Hauptknotentyp der Namensraum-Typ.\nFür alle anderen Achsen ist der Hauptknotentyp der Elementtyp.\nEin Knotentest, der ein QName ist, ist genau dann erfüllt, wenn der Knotentyp (siehe [5 Datenmodell]) der Hauptknotentyp ist und einen erweiterten Namen besitzt, der gleich dem erweiterten Namen des QName ist. Beispielsweise wählt child::para die para-Kindelemente des Kontextknotens aus. Falls der Kontextknoten keine para-Kinder besitzt, ist das Ergebnis eine leere Knotenmenge. attribute::href wählt die href-Attribute des Kontextknotens aus. Falls der Kontextknoten keine href-Attribute besitzt, ist das Ergebnis eine leere Knotenmenge.\nDas Akronym QName steht für "qualifizierter Name" und bedeutet, dass der entsprechende Name aus einem optionalen Präfix und einem lokalen Bestandteil bestehen kann. Beide Teile werden durch einen Doppelpunkt voneinander getrennt. Durch das Präfix wird der Namensraum bestimmt, zu dem der lokale Name gehört. Im Beispiel xlink:href ist xlink das Präfix und href der lokale Bestandteil. Die obigen Beispiele verwenden Knotentests, die letztendlich nur lokale Namen sind, also keine Namensräume berücksichtigen.\nMöchte man auf das href-Attribut aus dem xlink-Namensraum zugreifen, wäre also zu schreiben: attribute::xlink:href. Entsprechend greift man per preceding-sibling::xhtml:h1 auf die dem Kontextknoten vorhergehenden h1-Elemente aus dem xhtml-Namensraum zu. Schließlich ein Beispiel für die Namensraumachse: namespace::xlink wählt genau den Namensraumknoten aus, der zum Präfix xlink gehört. Der qualifizierte Name eines Namensraumknotens enthält übrigens niemals ein Präfix, siehe [5.4 Namensraumknoten].\nWie in den Beispielen am Beginn des Kapitels bereits gezeigt wurde, eignet sich die Achse self, um innerhalb eines Prädikats bestimmte Elementtypen aus einer Knotenmenge herauszufiltern, wie z.B. in child::*[self::chapter or self::appendix]. Leider funktioniert eine analoge Vorgehensweise für Attribut- oder Namensraumknoten nicht. Das erweist sich insbesondere bei negativen Bedingungen als hinderlich. Möchte man z.B. alle Attribute bis auf das href-Attribut auswählen, leistet attribute::*[not(self::href)] leider nicht das Gewünschte. Dieser Ausdruck liefert nämlich nach wie vor alle Attribute. Da die self-Achse Elemente enthalten kann, ihr Hauptknotentyp somit der Elementtyp ist, sucht der Ausdruck self::href immer nach einem Element mit dem Namen href, niemals nach einem Attribut. Eine Lösung für dieses Problem besteht in der Auswertung des Attributnamens, siehe die Funktionen name und local-name.\nEin QName im Knotentest wird in einen erweiterten Namen unter Verwendung der Namensraumdeklarationen aus dem Kontext des Ausdrucks expandiert. Dies geschieht in der gleichen Weise wie bei Elementnamen in Start- und End-Tags, allerdings mit der Ausnahme, dass ein mit xmlns deklarierter voreingestellter Namensraum nicht genutzt wird: d.h. enthält QName kein Präfix, so ist der Namensraum-URI leer (das ist die gleiche Regel, nach der auch Attributnamen expandiert werden). Es ist ein Fehler, wenn der QName ein Präfix enthält, für das es keine Namensraumdeklaration im Kontext des Ausdrucks gibt.\nQualifizierte Namen werden also gemäß der Namensraum-Empfehlung [XML Names] expandiert. Das bedeutet insbesondere, dass in einem XPath-Ausdruck nicht das gleiche Präfix wie im betrachteten XML-Dokument benutzt werden muss. Wichtig ist nur, dass beide Präfixe den gleichen Namensraum repräsentieren. Wenn beispielsweise das zugrunde liegende XML-Dokument ein XHTML-Dokument ist, dessen Elemente zum Namensraum http://www.w3.org/1999/xhtml gehören, so kann beispielsweise das Dokumentelement über den XPath-Ausdruck /child::xhtml:html ausgewählt werden – vorausgesetzt, das Präfix xhtml wurde im Kontext des Ausdrucks an den gleichen Namensraum gebunden. Dabei ist es völlig unerheblich, welches Präfix im XHTML-Dokument benutzt wurde – es ist sogar möglich, dass dort nur eine Deklaration für den voreingestellten Namensraum vorkommt: <html xmlns="http://www.w3.org/1999/xhtml">.\nGerade in diesen Fällen ist Vorsicht geboten. Sehr leicht übersieht man eine solche Namensraumdeklaration, die sich selbstverständlich auch auf alle Kindelemente auswirkt, und ist gewillt, nur den jeweiligen Elementnamen in einem Ausdruck anzugeben, z.B. bei folgender XSLT-Anweisung: <xsl:value-of select="title" />. Richtig wäre stattdessen (der Vollständigkeit halber mit Namensraumdeklaration): <xsl:value-of select="xhtml:title" xmlns:xhtml="http://www.w3.org/1999/xhtml">. Entsprechend müssen in Lokalisierungpfaden alle Schritte vollständig qualifiziert sein: xhtml:div/xhtml:p.\nStellt man fest, dass XPath-Ausdrücke nach dem Einfügen einer DTD in das Originaldokument nicht mehr die richtigen Knoten zurückliefern (was sich beispielsweise darin äußert, dass ein XSLT-Stylesheet nicht mehr die erwartete Ausgabe liefert), ist in der Regel ebenfalls die Deklaration eines voreingestellten Namensraums die Ursache. Eine Deklaration innerhalb der DTD der Form <!ATTLIST html xmlns CDATA #FIXED "http://www.w3.org/1999/xhtml"> versetzt alle Kindelemente von html ohne Präfix und auch html selbst in den XHTML-Namensraum. Ohne die DTD gehören sie keinem Namensraum an. In solchen Fällen sollte man die Deklaration des voreingestellten Namensraums in das XML-Dokument aufnehmen, damit XPath-Ausdrücke unabhängig von der Auswertung einer DTD immer das gleiche Ergebnis liefern.\nSchließlich sei noch einmal darauf hingewiesen, dass sich ein voreingestellter Namensraum im Kontext eines XPath-Ausdrucks nicht auf den Ausdruck auswirkt. Ein qualifizierter Name ohne Präfix adressiert damit immer ein Element oder ein Attribut, das zu keinem Namensraum gehört. Die folgende Variante ist damit keine Alternative zum obigen Beispiel: <xsl:value-of select="title" xmlns="http://www.w3.org/1999/xhtml">.\nEin Knotentest * ist für jeden Knoten des Hauptknotentyps erfüllt. Beispielsweise wählt child::* alle Kindelemente und attribute::* alle Attributknoten des Kontextknotens aus.\nHandelt es sich beim Kontextknoten um einen Elementknoten, so liefert der Schritt parent::* nur dann die leere Knotenmenge, wenn dieser das Dokumentelement repräsentiert. Der Elementknoten für das Dokumentelement besitzt zwar ebenfalls einen Elternknoten, nämlich die Wurzel /, diese ist aber nicht vom Hauptknotentyp der Achse parent, dem Elementtyp.\nEin Knotentest kann in der Form NCName:* auftreten. In diesem Fall wird das Präfix wie bei einem QName unter Verwendung der Namensraumdeklarationen des Kontextes expandiert. Es ist ein Fehler, wenn es für das Präfix keine Namensraumdeklaration im Kontext des Ausdrucks gibt. Der Knotentest ist erfüllt für jeden Knoten des Hauptknotentyps, dessen erweiterter Name den Namensraum-URI besitzt, zu dem das Präfix expandiert, unabhängig vom lokalen Bestandteil des Namens.\nBeispielsweise wählt descendant::xhtml:* alle Nachkommen aus dem xhtml-Namensraum und attribute::xlink:* alle Attribute aus dem xlink-Namensraum aus.\nDiese Form von Knotentests kann in einem XSLT-Stylesheet innerhalb eines Musters z.B. dazu genutzt werden, alle Elemente eines bestimmten Namensraums in der gleichen Weise zu behandeln. Eingebettete XHTML-Elemente in einem beliebigen zu transformierenden XML-Dokument können auf diese Weise einfach in die Ausgabe kopiert werden, ohne dass diese Elemente explizit benannt werden müssen.\nDer Knotentest text() ist erfüllt für jeden Textknoten. Zum Beispiel wählt child::text() alle Textknoten aus, die Kinder des Kontextknotens sind. Analog ist der Knotentest comment() für jeden Kommentarknoten erfüllt und der Knotentest processing-instruction() für jede Processing Instruction. Dem Test processing-instruction() kann ein Literal als Argument übergeben werden. In diesem Fall ist der Test für jede Processing Instruction erfüllt, deren Name gleich dem Wert des übergebenen Literals ist.\nOffensichtlich werden Kommentare nicht einfach ignoriert, sondern durch eigene Knoten innerhalb des XML-Baumes repräsentiert. Auf diese Weise können XPath-Ausdrücke mittels comment() auch auf Kommentarknoten zugreifen. Ein Stylesheet kann damit XML-Kommentare verarbeiten und diese geeignet darstellen.\nFür Processing Instructions gibt es ebenfalls entsprechende Knoten im XML-Baum. Jede Processing Instruction besitzt einen Namen (ein Ziel), z.B. xml-stylesheet in <?xml-stylesheet href=... ?>. Wird dieser Name im Knotentest processing-instruction() angegeben, ist der entsprechende Test nur für Processing Instructions mit gleichem Namen erfüllt. Namen von Processing Instructions werden dabei nicht von Namensraumdeklarationen beeinflusst. Das Argument für processing-instruction() ist damit kein qualifizierter Name, sondern ein Zeichenkettenliteral. Der Knotentest für die zitierte Processing Instruction lautet z.B. processing-instruction('xml-stylesheet').\nMöchte man alle Knoten eines Dokuments auswählen, kann man z.B. die folgenden Knotenmengen vereinigen: /descendant-or-self::node(), /descendant-or-self::node()/attribute::* und /descendant-or-self::node()/namespace::*.\nEs wurde bereits auf die Sonderrolle von Attribut- und Namensraumknoten hingewiesen. Diese werden nicht durch einen Knotentest, sondern durch entsprechende Achsen ausgewählt. Das hat zur Folge, dass sich zwar einfach prüfen lässt, ob der Kontextknoten z.B. ein Textknoten ist (per self::text(); analog für Element-, Kommentar- und Processing-Instruction-Knoten), allerdings funktioniert diese Methode nicht bei Attribut- und Namensraumknoten. Hier muss man stattdessen überprüfen, ob sich der Kontextknoten in der Menge der Attribut- bzw. Namensraumknoten des Elternknotens befindet, siehe [3.3 Knotenmengen].\nEine Achse ist entweder vorwärts- oder rückwärtsgerichtet. Eine vorwärtsgerichtete Achse enthält immer nur den Kontextknoten oder Knoten, die nach dem Kontextknoten im Dokument auftreten. Eine rückwärtsgerichtete Achse enthält immer nur den Kontextknoten oder Knoten, die vor dem Kontextknoten im Dokument auftreten. Demzufolge sind die Achsen ancestor, ancestor-or-self, preceding und preceding-sibling rückwärtsgerichtete Achsen. Alle anderen Achsen sind vorwärtsgerichtet. Da die Achse self immer höchstens einen Knoten enthält, hat es keine Bedeutung, ob sie als vorwärts- oder rückwärtsgerichtete Achse betrachtet wird. Die Näheposition eines Knotens in einer Knotenmenge bezüglich einer Achse ist definiert als die Position des Knotens in dieser Knotenmenge, welche in Dokumentordnung geordnet ist, wenn es sich um eine vorwärtsgerichtete Achse handelt, und welche in umgekehrter Dokumentordnung geordnet ist, wenn es sich um eine rückwärtsgerichtete Achse handelt. Die erste Position ist 1.\nDiese recht komplizierte Definition bedarf einer Erläuterung. Die Knoten in einer Knotenmenge sind ungeordnet – es handelt sich schließlich um eine Menge. Allerdings kann über die Funktion position die Position eines Knotens in der aktuellen Knotenliste bestimmt werden. Die Reihenfolge der Knoten orientiert sich an der Reihenfolge, in der die Knoten im XML-Dokument auftreten. Bei vorwärtsgerichteten Achsen wird diese Ursprungsreihenfolge beibehalten und man spricht von Dokumentordnung. Für rückwärtsgerichtete Achsen wird die Reihenfolge umgekehrt und man spricht von umgekehrter Dokumentordnung.\nDie obige Definition hat zur Folge, dass innerhalb eines Lokalisierungsschrittes immer der nächstgelegene Knoten die Position 1 hat. Abhängig von der Blickrichtung kann es sich um einen unmittelbaren Vorgänger (preceding) bzw. Vorfahren (ancestor) oder aber um einen unmittelbaren Nachfolger (following) bzw. Nachkommen (descendant) handeln. Der Begriff Näheposition beschreibt damit die Nähe zum Kontextknoten. Die Abbildungen zu den verschiedenen Achsen in Kapitel [2.2 Achsen] verdeutlichen die Näheposition der jeweiligen zur Achse gehörenden Knoten. Genau genommen ist die parent-Achse ebenfalls rückwärtsgerichtet, allerdings enthält diese wie self maximal einen Knoten.\nDie Näheposition ist nur innerhalb von Prädikaten in Lokalisierungsschritten von Bedeutung, da hier die ausschlaggebende Achse bekannt ist. Die in [4.2 Zeichenkettenfunktionen] vorgestellte Funktion string (ebenso wie die Funktionen number und boolean) konvertiert dagegen bei einer Knotenmenge immer den ersten Knoten bezüglich der Dokumentordnung, unabhängig davon, auf welchem Weg diese Knotenmenge gebildet wurde.\nFür vorwärtsgerichtete Achsen gilt daher folgende Gleichheit (am Beispiel following):\nDies ist bei rückwärtsgerichteten Achsen nicht der Fall. Stattdessen gilt hier (am Beispiel preceding):\nDie XSLT-Anweisung xsl:value-of verwendet implizit die Funktion string, um einen Textknoten zu generieren. Will man also auf den Wert des ersten Knotens einer rückwärtsgerichteten Achse zugreifen, muss man diesen immer explizit durch ein Prädikat auswählen. Die Ausgabe des Wertes eines Attributs id des Vorgängerknotens erfolgt daher z.B. durch <xsl:value-of select="preceding::p[position()=1]/@id" />.\nFür Attribute und Namensraumknoten ist die Diskussion um Position und Richtung bedeutungslos. Das liegt daran, dass die Reihenfolge, in der Attribute und Namensraumdeklarationen im Start-Tag eines Elements angegeben wurden, als irrelevant angesehen wird. Informationen darüber sind daher nicht mehr im XML-Baum enthalten.\nEin Prädikat filtert eine Knotenmenge bezüglich einer Achse und produziert damit eine neue Knotenmenge. Für jeden zu filternden Knoten der Knotenmenge wird der dazugehörige Ausdruck PredicateExpr berechnet, und zwar mit diesem Knoten als Kontextknoten, der Anzahl der Knoten der Knotenmenge als Kontextgröße und mit der Näheposition des Knotens in der Knotenmenge bezüglich der Achse als Kontextposition. Falls die Berechnung von PredicateExpr für diesen Knoten wahr ergibt, wird der Knoten in die Ergebnisknotenmenge aufgenommen, andernfalls nicht.\nancestor::person[position() >= 2]\nAchse und Knotentest ancestor::person liefern die Menge aller person-Elemente, die Vorfahren des Kontextknotens sind. Für jeden dieser Elementknoten wird nun der Ausdruck position() >= 2 berechnet. Die Kontextgröße ist dabei die Anzahl aller person-Vorfahren. Da ancestor eine rückwärtsgerichtete Achse ist, werden die Knoten entgegen der Originalreihenfolge nummeriert. Damit werden alle person-Elementknoten bis auf den ersten (d.h. den nächsten) in die Ergebnisknotenmenge aufgenommen. Da als Knotentest des Lokalisierungsschrittes person verwendet wurde (und nicht *), muss es sich bei diesem ersten person-Elementknoten nicht um den Elternknoten handeln. Würde sich ein weiteres Prädikat an den obigen Ausdruck anschließen, wäre die gerade berechnete Ergebnisknotenmenge Ausgangspunkt für dieses Prädikat.\nFalls der Ausdruck eines nachfolgenden Prädikats nicht auf Kontextgröße oder -position zugreift, kann dieser Ausdruck bereits im ersten Prädikat berechnet und über den logischen Operator and mit dem dortigen Ausdruck verbunden werden. Der Lokalisierungsschritt\nEin PredicateExpr wird durch Berechnung des Expr und anschließender Konvertierung des Ergebnisses in einen booleschen Wert bestimmt. Falls das Ergebnis eine Zahl war, wird es für den Fall, dass diese Zahl gleich der Kontextposition ist, in den Wert wahr konvertiert, ansonsten in den Wert falsch. Wenn das Ergebnis keine Zahl war, dann wird es so konvertiert wie bei einem Aufruf der Funktion boolean. Damit ist ein Lokalisierungspfad para äquivalent zu para[position()=3].\nDa die abgekürzte Syntax erst im folgenden Kapitel beschrieben wird, sollte als Beispiel hier besser child::para verwendet werden.\nFür Zahlen als Wert eines PredicateExpr gilt hier eine Sonderregel. Diese ermöglicht eine Schreibweise, die dem Zugriff auf Feldelemente in anderen Programmiersprachen gleicht. Allerdings muss beachtet werden, dass ein Ausdruck child::para[$num] nur dann gleichbedeutend mit child::para[position()=$num] ist, wenn die Variable num tatsächlich eine Zahl, also ein Objekt vom Typ number enthält. Wenn sie stattdessen nur eine geeignete Zeichenkette enthält, wird der Variableninhalt gemäß der Funktion boolean in einen booleschen Wert konvertiert. Das Gleiche gilt für jedes andere Objekt, das sich in eine Zahl konvertieren ließe.\nZunächst einige Beispiele für Lokalisierungspfade, die die abgekürzte Syntax benutzen:\npara wählt die para-Kindelemente des Kontextknotens aus.\n* wählt alle Kindelemente des Kontextknotens aus.\ntext() wählt alle Textknoten aus, die Kinder des Kontextknotens sind.\n@name wählt das Attribut name des Kontextknotens aus.\npara[last()] wählt das letzte para-Kindelement des Kontextknotens aus.\n*/para wählt alle para-Enkelelemente des Kontextknotens aus.\n/doc/chapter/section wählt das zweite section-Element des fünften chapter-Elements von doc aus.\nchapter//para wählt die para-Elemente aus, die Nachkommen der chapter-Kindelemente des Kontextknotens sind.\n//para wählt alle para-Nachkommen der Dokumentwurzel aus und somit alle para-Elemente im gleichen Dokument wie der Kontextknoten.\n//olist/item wählt all die item-Elemente aus dem gleichen Dokument wie der Kontextknoten aus, die ein olist-Elternelement besitzen.\n.//para wählt die para-Elemente aus, die Nachkommen des Kontextknotens sind.\n.. wählt den Elternknoten des Kontextknotens aus.\n../@lang wählt das Attribut lang des Elternknotens des Kontextknotens aus.\npara[@type="warning"] wählt alle para-Kindelemente des Kontextknotens aus, die ein Attribut type mit dem Wert warning besitzen.\npara[@type="warning"] wählt das fünfte para-Kindelement des Kontextknotens aus, das ein Attribut type mit dem Wert warning besitzt.\npara[@type="warning"] wählt das fünfte para-Kindelement des Kontextknotens aus, falls dieses Kind ein Attribut type mit dem Wert warning besitzt.\nchapter[title="Introduction"] wählt die chapter-Kindelemente des Kontextknotens aus, die ein oder mehrere title-Kindelemente mit einem Zeichenkettenwert gleich Introduction besitzen.\nchapter[title] wählt die chapter-Kindelemente des Kontextknotens aus, die ein oder mehrere title-Kindelemente besitzen.\nemployee[@secretary and @assistant] wählt alle employee-Kindelemente des Kontextknotens aus, die sowohl ein Attribut secretary als auch ein Attribut assistant besitzen.\nDie wichtigste Abkürzung besteht darin, dass child:: in einem Lokalisierungsschritt weggelassen werden kann. Die Standardachse ist also child. So steht beispielsweise ein Lokalisierungspfad div/para abkürzend für child::div/child::para.\nFür Attribute gibt es ebenfalls eine Abkürzung: attribute:: kann zu @ abgekürzt werden. Ein Lokalisierungspfad para[@type="warning"] steht beispielsweise abkürzend für child::para[attribute::type="warning"] und wählt damit para-Kindelemente mit einem Attribut type aus, dessen Wert gleich warning ist.\n// ist die Abkürzung für /descendant-or-self::node()/. Zum Beispiel steht //para abkürzend für /descendant-or-self::node()/child::para und wählt damit alle para-Elemente im Dokument aus (selbst ein para-Element, das ein Dokumentelement ist, wird durch //para ausgewählt, da der Dokumentelementknoten ein Kind des Wurzelknotens ist). div//para steht abkürzend für div/descendant-or-self::node()/child::para und wählt daher alle para-Nachfolger von div-Kindern aus.\nHier enthält das Originaldokument einen kleinen Fehler. Der vollständige Lokalisierungspfad für das letzte Beispiel muss child::div/descendant-or-self::node()/child::para lauten.\nAnmerkung: Der Lokalisierungspfad //para bedeutet nicht das Gleiche wie /descendant::para. Der zweite wählt das erste Nachkommenelement para aus, der erste wählt alle para-Nachkommen aus, die das erste Kind ihrer Eltern sind.\nDavon kann man sich durch Bestimmung des vollständigen Ausdrucks leicht überzeugen:\nDas Prädikat  wirkt damit auf die durch die child-Achse im zweiten Lokalisierungsschritt bestimmte Knotenmenge, wogegen es in /descendant::para zur descendant-Achse gehört.\nEin Lokalisierungsschritt . steht abkürzend für self::node(). Das ist insbesondere in Verbindung mit // nützlich. Der Lokalisierungspfad .//para steht zum Beispiel abkürzend für\nund wählt daher alle para-Elemente aus, die Nachkommen des Kontextknotens sind.\nAnalog steht der Lokalisierungsschritt .. abkürzend für parent::node(). Zum Beispiel steht ../title abkürzend für parent::node()/child::title und wählt damit die title-Kindelemente des Elternknotens des Kontextknotens aus.\nEine Variablenreferenz (VariableReference) ergibt den Wert, der an den Variablennamen innerhalb der Menge der Variablenbelegungen des Kontexts gebunden ist. Es ist ein Fehler, falls dem Variablennamen in der Menge der Variablenbelegungen aus dem Kontext des Ausdrucks kein Wert zugewiesen wurde.\nDer Name einer Variablen ist ein qualifizierter Name, kann also ein Präfix enthalten, das auf einen Namensraum verweist. Mittels des Zeichens $ wird auf den Wert einer Variablen zugegriffen.\nDer letzte Satz des obigen Abschnitts bedeutet, dass Variablen vor ihrer Benutzung definiert worden sein müssen. Wie bereits erwähnt, sieht XPath dafür keinerlei Sprachelemente vor. In [XSLT] verwendete Variablen haben immer einen definierten Wert. So wird durch das leere Element <xsl:variable name="foo:var" /> eine Variable namens foo:var definiert und mit der leeren Zeichenkette belegt.\nEin Ausdruck, der ein Funktionsaufruf (FunctionCall) ist, wird ausgewertet, indem anhand des Funktionsnamens (FunctionName) die Funktion in der Funktionsbibliothek des Ausdruckskontexts bestimmt, jedes der Argumente (Argument) berechnet und in den von der Funktion erwarteten Typ konvertiert und schließlich die Funktion mit den konvertierten Argumenten aufgerufen wird. Es ist ein Fehler, wenn eine falsche Anzahl von Argumenten übergeben wird oder eines der Argumente nicht in den geforderten Typ konvertiert werden kann. Das Ergebnis des Funktionsaufrufes (FunctionCall) ist der von der Funktion zurückgelieferte Wert.\nDie Konvertierung eines Arguments in den Typ string geschieht so wie beim Aufruf der Funktion string. Die Konvertierung eines Arguments in den Typ number geschieht so wie beim Aufruf der Funktion number. Die Konvertierung eines Arguments in den Typ boolean geschieht so wie beim Aufruf der Funktion boolean. Ein Argument, das nicht vom Typ node-set ist, kann nicht in eine Knotenmenge konvertiert werden.\nDieser letzte Satz stimmt insofern, als es keine automatische Konvertierung in eine Knotenmenge gibt. Zusätzliche Funktionen können durchaus Werte anderer Typen als Parameter entgegennehmen und eine Knotenmenge zurückliefern. In vielen XSLT-1.0-konformen Prozessoren existiert beispielsweise eine Erweiterungsfunktion node-set, die für einen Ergebnisteilbaum dessen äquivalente Knotenmenge zurückliefert.\nEin Lokalisierungspfad kann als Ausdruck benutzt werden. Ein solcher Ausdruck liefert die durch den Pfad ausgewählte Knotenmenge.\nDer Operator | berechnet die Vereinigung seiner Operanden, welche jeweils Knotenmengen sein müssen.\nDa es sich um eine Vereinigung von Mengen handelt, ist ein identischer Knoten in beiden Operanden in der Ergebnisknotenmenge auch nur einmal vorhanden. Zusammen mit der Funktion count (siehe [4.1 Funktionen auf Knotenmengen]) lässt sich so die Identität zweier Knoten feststellen.\nDie Knotenmenge $a ist in der Knotenmenge $b enthalten, falls count($b) = count($a | $b). $a und $b sind identisch, wenn $a in $b und $b in $a enthalten ist. Es handelt sich um einzelne Knoten, wenn außerdem count($a) = 1 ist. Achtung: Der Operator = bestimmt die Gleichheit der Zeichenkettenwerte zweier Knoten (siehe [3.4 Boolesche Werte]), nicht deren Identität.\nDamit lässt sich nun auch testen, ob der Kontextknoten ein Attributknoten ist (analog für Namensraumknoten):\nDie bedingte Auswahl einer Knotenmenge aus zwei Alternativen abhängig von einem logischen Ausdruck kann durch folgende Konstruktion erreicht werden:\nIn XSLT-Mustern, die eine Teilmenge der XPath-Ausdrücke bilden, wird der Operator | verwendet, um mögliche Alternativen anzugeben.\nPrädikate werden zum Filtern von Ausdrücken in der gleichen Weise wie in Lokalisierungspfaden benutzt. Es ist ein Fehler, falls das Ergebnis des zu filternden Ausdrucks keine Knotenmenge ist. Das Prädikat filtert die Knotenmenge bezüglich der Kindachse.\nAnmerkung: Die Bedeutung eines Prädikats hängt entscheidend davon ab, welche Achse angewendet wird. Zum Beispiel liefert preceding::foo das erste foo-Element in umgekehrter Dokumentordnung, weil die für das Prädikat  anzuwendende Achse die Vorgängerachse (preceding) ist. Demgegenüber liefert (preceding::foo) das erste foo-Element in Dokumentordnung, weil die Achse, die in diesem Fall für das Prädikat  gilt, die Kindachse ist.\nAuf diesen Unterschied soll noch einmal deutlich hingewiesen werden: Prädikate, die Bestandteil eines Lokalisierungsschrittes sind, filtern eine Knotenmenge bezüglich der im Lokalisierungsschritt verwendeten Achse. Für jeden Knoten der Knotenmenge ist daher dessen Näheposition relevant. Prädikate, die auf einen XPath-Ausdruck angewendet werden, interpretieren die betreffenden Knoten immer in Dokumentordnung, da laut Definition in solch einem Fall die Kindachse anzuwenden ist.\nIm obigen Beispiel preceding::foo ist das Prädikat  Bestandteil des Lokalisierungsschrittes preceding::foo, während bei (preceding::foo) das Prädikat  auf den Ausdruck (preceding::foo) angewendet wird (welcher in diesem Fall ein Lokalisierungsschritt ohne Prädikat ist).\nDas folgende Beispiel stellt den Sachverhalt aus einer praxisnäheren Sicht dar. Es gibt zwar die Achse ancestor-or-self, welche neben allen Vorfahren auch den Kontextknoten auswählt, es gibt aber keine entsprechende Achse preceding-or-self, die alle Vorgänger inklusive des Kontextknotens auswählen könnte. Die gewünschte Knotenmenge muss also durch eine Vereinigung konstruiert werden: preceding::node() | self::node(). Bei der Anwendung eines oder mehrerer Prädikate auf die entstehende Menge, etwa (preceding::node() | .)[@id], muss man beachten, dass die Knoten nun in Dokumentordnung gefiltert werden. Der Ausdruck liefert damit den ersten Knoten im Dokument, der ein Vorgänger des Kontextknotens ist und ein Attribut id besitzt, und nicht den zum Kontextknoten nächsten Knoten mit dieser Eigenschaft.\nBei der Betrachtung des Beispiels (preceding-sibling::* | following-sibling::*) wird klar, dass für solche Ausdrücke eine von den beteiligten Achsen abhängende Knotenordnung nicht praktikabel ist.\nAn dieser Stelle sei darauf hingewiesen, dass über die in [XSLT] definierte Funktion document auch Knotenmengen aus verschiedenen Dokumenten miteinander vereinigt werden können. In diesem Fall gibt es keine definierte Dokumentordnung für die Vereinigungsmenge mehr. Die Anwendung eines entsprechenden Prädikats ist damit implementationsabhängig. Entsprechendes gilt bei einer Knotenmenge, die die Attribute eines Elements enthält.\nDie Operatoren / und // verbinden einen Ausdruck und einen relativen Lokalisierungspfad. Es ist ein Fehler, wenn die Berechnung des Ausdrucks keine Knotenmenge ergibt. Der Operator / arbeitet dabei in der gleichen Weise wie in einem Lokalisierungspfad. Ebenso wie in Lokalisierungspfaden steht // abkürzend für /descendant-or-self::node()/.\nEs gibt keine Objekte, die in eine Knotenmenge konvertiert werden können.\nAngenommen, eine Variable namens divs enthält eine Knotenmenge von diversen div-Elementen (div1, div2, etc). Dann kann mittels $divs auf das erste dieser Elemente zugegriffen werden. $divs/@id liefert die Menge der id-Attributknoten der Elemente aus $divs, $divs//image liefert die Menge aller image-Elemente, die Nachkommen eines in $divs enthaltenen div-Elements sind.\nDabei ist zu beachten, dass sich einem Ausdruck anschließende Lokalisierungsschritte immer auf die Position der Knoten im XML-Dokument beziehen und nicht auf die durch den Ausdruck berechnete Knotenmenge. Beispielsweise bestimmt $divs/following-sibling::* den nachfolgenden Geschwisterknoten des ersten Knotens aus $divs im XML-Dokument, und nicht den "Nachfolger" in $divs, also $divs. Allgemein gesprochen gibt es keinen Weg, der es erlaubt, ausgehend von einem Kontextknoten, der Element einer zuvor bestimmten Knotenmenge ist, auf die anderen Knoten dieser Menge zuzugreifen. Das betrifft insbesondere Ausdrücke, die in Prädikaten oder im Körper der XSLT-Anweisung xsl:for-each auftreten.\nAusdrücke, speziell Variablen, dürfen nur vor / und // auftreten. Es ist nicht möglich, Ausdrücke dynamisch zusammenzusetzen, wie man es etwa mit /root/$element versuchen könnte. Eine Möglichkeit, innerhalb eines Pfades dynamisch ein bestimmtes Element auszuwählen, wird im Zusammenhang mit der Funktion name vorgestellt.\nWie schon gesagt wurde, muss ein Ausdruck, dem ein Prädikat oder einer der Operatoren / und // folgt, immer eine Knotenmenge als Ergebnis liefern. Da Objekte anderer Typen nicht in eine Knotenmenge konvertiert werden können, führt die Auswertung eines Ausdrucks, der keine Knotenmenge ergibt, in diesem Fall zu einem Fehler. XPath nutzende Spezifikationen und Implementationen können jedoch explizit zusätzliche Funktionen definieren, die beliebige Objekte in Knotenmengen überführen.\nDie Berechnung eines or-Ausdrucks erfolgt, indem jeder der Operanden berechnet und in einen booleschen Wert wie beim Aufruf der Funktion boolean konvertiert wird. Das Ergebnis ist der Wert wahr, wenn einer der beiden Werte wahr ist, und andernfalls falsch. Der rechte Operand wird nicht mehr ausgewertet, wenn der linke Operand wahr ergibt.\nDie Berechnung eines and-Ausdrucks erfolgt, indem jeder der Operanden berechnet und in einen booleschen Wert wie beim Aufruf der Funktion boolean konvertiert wird. Das Ergebnis ist der Wert wahr, wenn beide Werte wahr sind, und andernfalls falsch. Der rechte Operand wird nicht mehr ausgewertet, wenn der linke Operand falsch ergibt.\nSo arbeiten alle XSLT-Funktionen ohne Seiteneffekte (sie produzieren weder Ausgaben noch ändern sie Variableninhalte); Funktionsparameter werden automatisch in den geforderten Typ konvertiert und mathematische Operationen liefern immer einen definierten Wert. Lediglich Typfehler können auftreten, falls ein Ausdruck als Operand oder Funktionsparameter eine Knotenmenge verlangt. Allerdings gibt es in XPath keine Möglichkeit festzustellen, ob ein Teilausdruck vom Typ Knotenmenge ist.\nDie Berechnung eines EqualityExpr-Ausdrucks (der nicht allein ein RelationalExpr-Ausdruck ist) oder eines RelationalExpr-Ausdrucks (der nicht allein ein AdditiveExpr-Ausdruck ist) geschieht, indem die Objekte miteinander verglichen werden, die im Ergebnis der Auswertung der beiden Operanden entstehen. Die folgenden drei Absätze definieren den Vergleich zwischen den daraus resultierenden Objekten. Erst werden Vergleiche, die Knotenmengen betreffen, über Vergleiche definiert, die keine Knotenmengen betreffen; dies geschieht einheitlich für =, !=, <=, <, >= und >. Dann werden Vergleiche, die keine Knotenmengen betreffen, für = und != definiert. Schließlich werden Vergleiche, die keine Knotenmengen betreffen, für <=, <, >= und > definiert.\nWenn beide zu vergleichenden Objekte Knotenmengen sind, so liefert ein Vergleich genau dann den Wert wahr, wenn es einen Knoten aus der ersten Knotenmenge und einen Knoten aus der zweiten Knotenmenge gibt, sodass das Ergebnis des Vergleichs der Zeichenkettenwerte dieser beiden Knoten wahr ergibt. Wenn eines der zu vergleichenden Objekte eine Knotenmenge und das andere eine Zahl ist, dann liefert ein Vergleich genau dann den Wert wahr, wenn es einen Knoten in der Knotenmenge gibt, sodass der Vergleich zwischen der Zahl und dem Ergebnis der Konvertierung des Zeichenkettenwerts dieses Knotens zu einer Zahl über die Funktion number wahr ergibt. Wenn eines der zu vergleichenden Objekte eine Knotenmenge und das andere eine Zeichenkette ist, dann liefert ein Vergleich genau dann den Wert wahr, wenn es einen Knoten in der Knotenmenge gibt, sodass der Vergleich zwischen der Zeichenkette und dem Zeichenkettenwert dieses Knotens wahr ergibt. Wenn eines der zu vergleichenden Objekte eine Knotenmenge und das andere ein boolescher Wert ist, dann liefert ein Vergleich genau dann den Wert wahr, wenn es einen Knoten in der Knotenmenge gibt, sodass der Vergleich zwischen dem booleschen Wert und dem Ergebnis der Konvertierung des Zeichenkettenwerts dieses Knotens zu einem boolschen Wert über die Funktion boolean wahr ergibt.\nWenn keines der zu vergleichenden Objekte eine Knotenmenge ist und als Operator = oder != vorkommt, so werden die Objekte wie nachfolgend beschrieben in einen gemeinsamen Typ konvertiert und anschließend verglichen. Wenn wenigstens eines der zu vergleichenden Objekte ein boolescher Wert ist, wird jedes Objekt wie bei der Anwendung der Funktion boolean in einen booleschen Wert konvertiert. Wenn wenigstens eines der zu vergleichenden Objekte eine Zahl ist, wird jedes Objekt wie bei der Anwendung der Funktion number in eine Zahl konvertiert. Andernfalls werden beide Objekte wie bei der Anwendung der Funktion string in Zeichenketten konvertiert. Der Vergleich = liefert als Ergebnis genau dann den Wert wahr, wenn beide Objekte gleich sind; der Vergleich != liefert als Ergebnis genau dann den Wert wahr, wenn beide Objekte ungleich sind. Zahlen werden gemäß IEEE 754 [IEEE 754] verglichen. Zwei boolesche Werte sind gleich, wenn sie entweder beide wahr oder beide falsch sind. Zwei Zeichenketten sind genau dann gleich, wenn sie aus derselben Folge von UCS-Zeichen bestehen.\nAnmerkung: Wenn $x mit einer Knotenmenge belegt ist, dann bedeutet $x="foo" nicht dasselbe wie not($x!="foo"): Der erste Vergleich ergibt genau dann wahr, wenn ein Knoten in $x den Zeichenkettenwert foo hat; der zweite ergibt genau dann wahr, wenn alle Knoten in $x den Zeichenkettenwert foo haben.\nEin häufigerer Fall dürfte der Test auf Ungleichheit sein. Man möchte z.B. feststellen, ob der Wert eines Ausdrucks verschieden von allen Kindelementen entry ist. Die Lösung lautet in diesem Fall nicht entry!="foo" (hier wird auf alle entry-Kindelemente zugegriffen und getestet, ob unter diesen eines existiert, das verschieden von der Zeichenkette "foo" ist), sondern not(entry="foo").\nEs sei noch einmal darauf hingewiesen, dass für Knotenmengen mit den Operatoren = und != nicht die Identität von Knoten getestet wird, sondern die ihrer Zeichenkettenwerte. Zwei Knoten können unter Zuhilfenahme des Operators | auf Identität getestet werden, siehe Anmerkung in Kapitel [3.3 Knotenmengen].\nSomit sind Vergleiche, an denen Knotenmengen beteiligt sind, dann erfüllt, wenn sich wenigstens ein Knoten aus der jeweiligen Menge finden lässt, dessen Zeichenkettenwert den Vergleich erfüllt. Insbesondere liefert der Vergleich mit wenigstens einer leeren Menge in jedem Fall den Wert falsch. Sind nur Werte verschiedener skalarer Typen beteiligt, so wird in der Rangfolge "boolescher Wert – Zahl – Zeichenkette" ein gemeinsamer Typ gesucht und der jeweils andere Wert konvertiert. Größenvergleiche sind nur für Zahlen definiert.\nUnter Ausnutzung dieser Regeln kann z.B. die kleinste Zahl in einer Knotenmenge $set folgendermaßen bestimmt werden:\n$set[not(. > $set)]\nEin Vergleich mit dem speziellen Zahlenwert NaN (Not a Number) liefert immer den Wert falsch, selbst bei number('NaN')=number('NaN'). Bei 'NaN' handelt es sich hier nicht um eine spezielle Zeichenkette, die in den Wert NaN konvertiert wird, sondern einfach um eine, die sich nicht konvertieren lässt. Können in der Beispielmenge $set auch Knoten auftreten, deren Zeichenkettenwert sich nicht in eine Zahl konvertieren lässt, könnte man den obigen Ausdruck auf folgende, etwas unkonventionelle Weise vervollständigen:\n$set[number()=number() and not(. > $set)]\nVorsicht ist geboten, wenn die Werte einer Knotenmenge vor dem Vergleich durch eine Funktion mit skalarem Argumenttyp bearbeitet werden sollen. Übergibt man der Funktion die gesamte Knotenmenge als Argument, wird nur mit dem Funktionswert des ersten Knotens verglichen. Die spezielle Semantik des Vergleichs mit Knotenmengen geht verloren. In der Anmerkung zur Funktion normalize-space wird dies an einem Beispiel ausführlicher erläutert.\nXPath stellt keine Möglichkeit zur Verfügung, mit der man Zeichenketten lexikographisch der Größe nach vergleichen könnte. Abhängig vom Anwendungsfall lassen sich in XSLT solche Vergleiche durch die Programmierung rekursiver Templates oder die Benutzung des xsl:sort-Elements realisieren.\nAnmerkung: Wenn ein XPath-Ausdruck in einem XML-Dokument vorkommt, müssen alle Operatoren < und <= gemäß den XML-1.0-Regeln geschützt werden, zum Beispiel als < und <=. Im folgenden Beispiel ist der Wert des Attributes test ein XPath-Ausdruck:\nAnmerkung: Mit der obigen Grammatik ergibt sich folgende Vorrangfolge (kleinster Vorrang zuerst):\nAlle Operatoren sind links-assoziativ. Beispielsweise ist 3 > 2 > 1 äquivalent zu (3 > 2) > 1, was den Wert falsch ergibt.\nDer Vergleich 3 > 2 ergibt zunächst den Wert wahr. Dieses Ergebnis wird aufgrund des folgenden Vergleichsoperators > in die Zahl 1 konvertiert, sodass nun 1 > 1 berechnet wird, was den Wert falsch liefert. Auf analoge Weise kann man sich überlegen, dass der Ausdruck 2 = 1 = 0 wahr, der Ausdruck 0 = 0 = 0 hingegen falsch ergibt.\nHier ist Vorsicht geboten, da solche Ausdrücke gemäß der XPath-Grammatik erlaubt sind, aber nicht die Semantik besitzen, die man auf den ersten Blick erwarten würde. Sie verhalten sich allerdings genauso wie beispielsweise in den Programmiersprachen C und C++.\nEin Wert vom Typ number repräsentiert eine Gleitkommazahl. Eine Zahl kann jeden beliebigen, doppelt-genauen 64-Bit-Wert des Formats IEEE 754 [IEEE 754] annehmen. Dies beinhaltet den speziellen Wert "Not-a-Number" (NaN), positiv und negativ unendlich, sowie positiv und negativ Null. Für eine Zusammenfassung der wichtigsten Regeln des IEEE-754-Standards siehe Abschnitt 4.2.3 in [JLS].\nAn dieser Stelle sei bereits kurz auf die Produktion für Number in [3.7 Lexikalische Struktur] hingewiesen. Zahlen in XPath sind Gleitkommazahlen ohne Exponentendarstellung. Eine Schreibweise 2.99792E+08 ist nicht zulässig. Sie können ein negatives, aber kein explizites positives Vorzeichen besitzen. Soll einer der speziellen Werte wie z.B. positiv unendlich verwendet werden, muss dieser ermittelt werden, etwa durch 1 div 0.\nEs gibt in XPath weder einen speziellen Typ für ganzzahlige Werte noch gesonderte Zahlendarstellungen, die eine Zahl als Oktal- oder Hexadezimalzahl interpretieren, wie dies in vielen Programmiersprachen möglich ist.\nDie numerischen Operatoren konvertieren ihre Operanden in Zahlen, so wie bei einem Aufruf der Funktion number.\nGemäß Errata-Dokument [XPath Errata] ist die Semantik des einstelligen Operators - nicht spezifiziert. Stattdessen muss dieser letzte Absatz lauten:\nAnmerkung: Da XML innerhalb von Namen das Zeichen - erlaubt, muss der Operator - typischerweise von einem Leerraumzeichen angeführt werden. Zum Beispiel ergibt foo-bar eine Knotenmenge, die die Kindelemente namens foo-bar enthält; foo - bar ergibt die Differenz aus den Werten, die durch Konvertierung des Zeichenkettenwertes des ersten foo-Kindelements in eine Zahl und durch Konvertierung des Zeichenkettenwertes des ersten bar-Kindelements in eine Zahl entstehen.\nDer Operator * berechnet eine Gleitkomma-Multiplikation gemäß IEEE 754. Beachten Sie: Falls das Ergebnis nicht NaN ist, ist das Ergebnis genau dann positiv, wenn beide Operanden das gleiche Vorzeichen besitzen.\nDas Zeichen * dient zugleich als Knotentest zur Auswahl beliebiger Elemente. Welche Semantik ein * innerhalb eines XPath-Ausdrucks hat, hängt damit von den umgebenden Tokens in diesem Ausdruck ab (siehe [3.7 Lexikalische Struktur]).\nDer Operator div berechnet eine Gleitkomma-Division gemäß IEEE 754.\nBeachten Sie: Falls das Ergebnis nicht NaN ist, ist das Ergebnis genau dann positiv, wenn beide Operanden das gleiche Vorzeichen besitzen.\nDer Schrägstrich / ist nicht der Divisionsoperator, da dieser bereits als Pfadoperator zum Verbinden von Lokalisierungsschritten sowie als Symbol für den Wurzelknoten benutzt wird. Im Gegensatz zum Zeichen * gibt es hier nicht mehrere Interpretationsmöglichkeiten.\nDer Operator mod liefert den Rest einer ganzzahligen Division. Beispiele:\nAnmerkung: mod berechnet dasselbe wie der Operator % in Java und ECMAScript.\nDer mod-Operator berechnet den genauen Rest, der sich bei der ganzzahligen Division zweier Gleitkommazahlen ergibt, ohne die Operanden zuvor auf ganze Zahlen zu runden.\nZeichenketten bestehen aus einer Folge von null oder mehr Zeichen, wobei Zeichen wie in der XML-Empfehlung [XML] definiert sind. Ein einzelnes XPath-Zeichen entspricht damit einem einzelnen abstrakten Unicode-Zeichen mit einem einzelnen korrespondierenden skalaren Wert (siehe [Unicode]); dies unterscheidet sich allerdings von einem 16-Bit-kodierten Unicode-Zeichen: Die durch Unicode definierte kodierte Zeichenrepräsentation eines abstrakten Zeichens mit einem skalaren Wert größer als U+FFFF ist ein Paar von 16-Bit Unicode-Codes (ein Surrogat-Paar). In vielen Programmiersprachen wird eine Zeichenkette als Folge von 16-Bit-kodierten Unicode-Zeichen repräsentiert; XPath-Implementationen in solchen Sprachen müssen sicherstellen, dass ein Surrogat-Paar korrekt als einzelnes XPath-Zeichen behandelt wird.\nAnmerkung: In Unicode ist es möglich, dass zwei Zeichenketten als identisch anzusehen sind, obwohl sie aus unterschiedlichen Folgen abstrakter Unicode-Zeichen bestehen. Zum Beispiel können einige Akzentzeichen entweder in einer vordefinierten (precomposed) oder einer zerlegten (decomposed) Form repräsentiert werden. Damit können XPath-Ausdrücke unerwartete Resultate liefern, es sei denn, sowohl die Zeichen im XPath-Ausdruck als auch die im XML-Dokument wurden zu einer kanonischen Form normalisiert (siehe [Character Model]).\nEin zusammengesetztes Zeichen, das sich auch als vordefiniertes Zeichen kodieren lässt, wird durch einen einzigen Unicode-Code repräsentiert. Beispielsweise lässt sich der Umlaut »ü« als U+00FC darstellen. Zugleich kann dieser Buchstabe auch wie jedes zusammengesetzte Zeichen in der zerlegten Form durch die Folge der beiden Codes U+0075 (»u«) und U+0308 (combining diaeresis) kodiert werden.\nBeim Zerlegen in einzelne Tokens wird immer das längstmögliche Token zurückgeliefert.\nZur besseren Lesbarkeit können Leerraumzeichen innerhalb von Ausdrücken verwendet werden, auch wenn es nicht explizit durch die Grammatik erlaubt wurde: ExprWhitespace kann innerhalb von Ausdrücken frei vor oder nach beliebigen ExprTokens eingefügt werden.\nAn dieser Stelle sei auf die Anmerkung zum Operator für die Subtraktion, das zweistellige Minus, in [3.5 Zahlen] hingewiesen. Der erste Absatz legt fest, dass »foo-bar« nur als einzelnes Token interpretiert werden darf und nicht als Folge der Tokens »foo«, »-« und »bar«. Der zweite Absatz erlaubt nun explizit, beispielsweise den Minus-Operator mittels Leerraumzeichen als einzeln zu interpretierendes Token zu kennzeichnen.\nÜblicherweise unterscheidet man bei der Definition einer Sprache zwischen lexikalischen Produktionen, die den Aufbau der lexikalischen Einheiten, so genannter Tokens festlegen, und syntaktischen Produktionen, die die mögliche Kombination dieser Tokens zu komplexeren Konstrukten beschreiben. In der XPath-Spezifikation sind diese beiden Arten von Produktionen allerdings nicht streng voneinander abgegrenzt. Der Hauptunterschied zwischen lexikalischen und syntaktischen Produktionen besteht darin, dass zwischen einzelnen Tokens Leerraumzeichen auftreten dürfen, nicht jedoch innerhalb eines Tokens. Die Produktion für das Nichtterminal ExprToken stellt damit die oberste lexikalische Produktion dar. Daraus ergibt sich, dass ein Leerzeichen zwischen @ und einem QName zur Abkürzung der attribute-Achse erlaubt ist, nicht aber zwischen $ und einem QName bei Variablenreferenzen.\nDie folgenden speziellen Regeln für die Zerlegung in Tokens müssen in der angegebenen Reihenfolge angewendet werden, um die Grammatik ExprToken eindeutig zu machen:\nWenn es ein vorhergehendes Token gibt und dieses Token kein @, ::, (, [, , oder ein Operator ist, dann muss ein * als MultiplyOperator und ein NCName als OperatorName erkannt werden.\nFalls das einem NCName folgende Zeichen (möglicherweise nach dazwischenliegendem ExprWhitespace) das Zeichen ( ist, dann muss das Token als NodeType oder als FunctionName erkannt werden.\nFalls die einem NCName folgenden beiden Zeichen (möglicherweise nach dazwischenliegendem ExprWhitespace) die Zeichen :: sind, dann muss das Token als AxisName erkannt werden.\nIm zweiten Aufzählungspunkt des Originaldokuments hat sich ein Fehler eingeschlichen. Da Funktionsnamen mit einem Präfix ausgestattet sein können, muss laut Errata-Dokument [XPath Errata] auf QName statt auf NCName verwiesen werden. Alle Standardfunktionen aus XPath, XSLT und XPointer besitzen zwar nur Namen ohne Präfix, der Erweiterungsmechanismus in XSLT erlaubt jedoch XSLT-Implementationen, zusätzliche Funktionen aus einem proprietären Namensraum zur Verfügung zu stellen.\nDas hier diskutierte Problem der Mehrdeutigkeit umgeht man in vielen anderen Programmiersprachen durch die Definition von Schlüsselwörtern, die dann für frei wählbare Bezeichner nicht mehr zur Verfügung stehen. Ein XML-Autor ist jedoch frei in seiner Wahl der Element- und Attributnamen, also muss auch die Sprache XPath damit umgehen können. Die gefundene Regelung ermöglicht eine kompakte Schreibweise für XPath-Ausdrücke und bürdet die Last der eindeutigen Interpretation der jeweiligen XPath-Implementation auf.\nbestimmt jeweils den in eine Zahl konvertierten Zeichenkettenwert der ersten Knoten in den durch * repräsentierten Knotenmengen aller Kindelemente und multipliziert diese miteinander, d.h. das erste und dritte * werden als Lokalisierungspfad, das mittlere * als Multiplikationsoperator interpretiert.\nergibt den Wert wahr, wenn die aktuelle Kontextposition mit dem in eine Zahl konvertierten Zeichenkettenwert eines Kindelements namens position übereinstimmt (Funktionsname versus Elementname).\nergibt den Wert wahr, wenn der Kontextknoten ein Kindelement namens parent oder ein Elternelement namens child besitzt (Achsenname versus Elementname).\nDieser Abschnitt beschreibt die Funktionen, die bei einer XPath-Implementation immer in der bei der Auswertung von Ausdrücken benutzten Funktionsbibliothek enthalten sein müssen.\nJede Funktion in der Funktionsbibliothek wird über einen Funktionsprototypen spezifiziert, der den Rückgabetyp, den Namen der Funktion und die Typen der Argumente angibt. Falls ein Argument von einem Fragezeichen gefolgt wird, so ist es optional; andernfalls ist es obligatorisch.\nEin Funktionsargument, dem ein Stern * folgt, darf keinmal, einmal oder mehrmals auftreten. Der Argumenttyp object steht für einen beliebigen Typ.\nDie Funktion last liefert eine Zahl, die gleich der Kontextgröße des Kontexts des ausgewerteten Ausdrucks ist.\nDie Funktion position liefert eine Zahl, die gleich der Kontextposition im Kontext des ausgewerteten Ausdrucks ist.\nDie Funktion count liefert die Anzahl der Knoten der übergebenen Knotenmenge.\nFür den letzten Knoten einer Knotenmenge gilt damit die Gleichheit position()=last(). Beachten Sie, dass die Nummerierung der Knoten bei 1 beginnt.\nWährend last also die Kontextgröße zurückgibt, d.h. die Anzahl der Knoten der Knotenmenge, in der sich der Kontextknoten befindet, berechnet count die Anzahl der Knoten einer beliebigen als Argument zu übergebenden Knotenmenge. Es gibt keinen XPath-Ausdruck, der für einen beliebigen Knoten dessen Position in einer vorgegebenen Knotenmenge berechnet.\nIn bestimmten Situationen lässt sich jedoch das Wissen über die Art der Beziehungen der Knoten in der Knotenmenge ausnutzen. Möchte man beispielsweise herausfinden, welche Position das erste para-Kind mit dem Attribut type="warning" unter allen para-Kindern besitzt, kann man einfach die diesem Element vorangehenden para-Geschwister zählen und 1 addieren:\nDiese Methode funktioniert hier deshalb, weil klar ist, dass alle para-Elemente Geschwister sind und auf die vorherigen Knoten der Menge daher über die Achse preceding-sibling zugegriffen werden kann. Wenn nicht bekannt ist, wie die Knotenmenge gebildet wurde, können die anderen Knoten auch nicht bestimmt und gezählt werden.\nIn Kapitel [3.3 Knotenmengen] wird im Zusammenhang mit dem Mengenvereinigungsoperator | gezeigt, wie die Funktion count zur Bestimmung von Durchschnitt und Differenz zweier Mengen genutzt werden kann.\nDie Funktion id wählt Elemente anhand ihrer eindeutigen ID aus (siehe [5.2.1 Eindeutige IDs]). Wenn als Argument eine Knotenmenge übergeben wird, so ergibt sich das Ergebnis aus der Vereinigung der Knotenmengen, die durch den Aufruf von id mit dem Zeichenkettenwert jedes Knotens aus der übergebenen Knotenmenge berechnet werden. Ist das Argument der Funktion id von einem beliebigen anderen Typ, so wird es wie bei einem Aufruf der Funktion string in eine Zeichenkette konvertiert; die Zeichenkette wird in eine durch Leerraumzeichen getrennte Liste von Tokens aufgeteilt (Leerraumzeichen sind beliebige Folgen von Zeichen, die sich aus der Produktion S ableiten lassen). Das Ergebnis ist eine Knotenmenge, die die Elemente aus dem Dokument des Kontextknotens enthält, die eine eindeutige ID mit dem gleichen Wert wie eines der Tokens der Liste besitzen.\nid("foo") wählt die Elemente mit der eindeutigen ID foo aus.\nid("foo")/child::para[position()=5] wählt das fünfte para-Kindelement des Elements mit der eindeutigen ID foo aus.\nDiese Funktion ermöglicht die Auswertung von Attributen des Typs IDREF bzw. IDREFS. Da ein IDREF-Wert als ID an ein Element im gleichen XML-Dokument vergeben worden sein muss, lässt sich dieses Element mit Hilfe der Funktion id bestimmen. Handelt es sich um mehrere IDs als Wert eines IDREFS-Attributs, liefert id alle zugehörigen Elemente als Knotenmenge.\nDie Knoten in der Ergebnisknotenmenge werden durch ein folgendes Prädikat in Dokumentordnung gefiltert und nicht in der Reihenfolge der angegebenen IDs.\nDie Funktion id kann aber nur korrekt arbeiten, wenn ID-wertige Attribute als solche erkannt werden. Dazu muss die DTD bekannt und vom Parser ausgewertet worden sein. Dies ist einer der wenigen Fälle, in denen das Ergebnis eines XPath-Ausdrucks von der Kenntnis der DTD des Dokuments abhängt. Fehlt diese Information, liefert id immer eine leere Knotenmenge.\nEs gibt keine komplementäre Funktion, die für ein Element dessen ID zurückliefert. Unter Zuhilfenahme von id lässt sich diese Information allerdings herausfinden. Gesucht ist nämlich genau das Attribut, für das die Funktion id den Elternknoten dieses Attributs liefert:\nDie Funktion local-name liefert den lokalen Teil des erweiterten Namens des ersten Knotens in der Argumentknotenmenge bezüglich der Dokumentordnung. Falls die übergebene Knotenmenge leer ist oder der erste Knoten keinen erweiterten Namen besitzt, wird eine leere Zeichenkette zurückgegeben. Wird kein Argument übergeben, wird stattdessen eine Knotenmenge mit dem Kontextknoten als einzigem Element benutzt.\nFür Element- und Attributknoten gilt damit, dass die Funktion local-name den dem Doppelpunkt folgenden Teil des QName zurückgibt bzw. den vollständigen Namen, wenn dieser kein Präfix enthält. Die folgenden Beispiele demonstrieren dies unter der Voraussetzung, dass der als jeweiliges Argument übergebene Lokalisierungspfad nicht die leere Knotenmenge ergibt:\nFür Namensraumknoten liefert local-name das zugewiesene Präfix, also beispielsweise für die Deklaration xmlns:xlink="http://www.w3.org/1999/xlink" die Zeichenkette »xlink«. Für Namensraumknoten, die den voreingestellten Namensraum repräsentieren, wird die leere Zeichenkette zurückgegeben.\nFür Processing Instructions liefert local-name das jeweilige Ziel, also beispielsweise für <?xml-stylesheet href='style.xsl'?> die Zeichenkette »xml-stylesheet«.\nDie Funktion namespace-uri liefert den Namensraum-URI des erweiterten Namens des ersten Knotens in der Argumentknotenmenge bezüglich der Dokumentordnung. Falls die übergebene Knotenmenge leer ist, der erste Knoten keinen erweiterten Namen besitzt oder der Namensraum-URI des erweiterten Namens leer ist, wird eine leere Zeichenkette zurückgegeben. Wird kein Argument übergeben, wird stattdessen eine Knotenmenge mit dem Kontextknoten als einzigem Element benutzt.\nAnmerkung: Die von der Funktion namespace-uri zurückgegebene Zeichenkette ist außer für Element- oder Attributknoten immer leer.\nBeispiele: namespace-uri(xhtml:body) liefert den zum Präfix xhtml gehörenden Namensraum-URI (z.B. »http://www.w3.org/1999/xhtml«), entsprechend ergibt namespace-uri(@xlink:href) die Zeichenkette »http://www.w3.org/1999/xlink«, falls das Präfix xlink an diesen URI gebunden wurde. Für Elementknoten aus dem voreingestellten Namensraum liefert namespace-uri den dazugehörigen URI. Für Element- und Attributknoten, die keinem Namensraum angehören, wird die leere Zeichenkette zurückgegeben.\nDie Funktion name liefert eine Zeichenkette mit einem QName, die den erweiterten Namen des ersten Knotens in der Argumentknotenmenge bezüglich der Dokumentordnung repräsentiert. Der QName muss den erweiterten Namen unter Berücksichtigung der Namensraumdeklarationen repräsentieren, die für den Knoten gültig sind, dessen erweiterter Name repräsentiert wird. Typischerweise ist das der QName, der in der XML-Quelle vorkommt. Das muss nicht der Fall sein, wenn es für den Knoten Namensraumdeklarationen gibt, die dem gleichen Namensraum mehrere Präfixe zuordnen. Allerdings kann eine Implementation Informationen über das Originalpräfix speichern; in diesem Fall kann die Implementation sicherstellen, dass der zurückgegebene String immer der in der XML-Quelle benutzte QName ist. Falls die übergebene Knotenmenge leer ist oder der erste Knoten keinen erweiterten Namen besitzt, wird eine leere Zeichenkette zurückgegeben. Wird kein Argument übergeben, wird stattdessen eine Knotenmenge mit dem Kontextknoten als einzigem Element benutzt.\nAnmerkung: Die von der Funktion name gelieferte Zeichenkette ist die gleiche wie die von der Funktion local-name gelieferte, außer für Element- und Attributknoten.\nFür einen folgendermaßen definierten Elementknoten\n<x:foo xmlns:x="urn:bar" xmlns:y="urn:bar" />\ndarf die Funktion name damit die Zeichenkette »y:foo« liefern, da durch das Präfix y der gleiche Namensraum repräsentiert wird wie durch x.\nDie drei Funktionen local-name, namespace-uri und name werden in der folgenden Tabelle kurz zusammengefasst. Das Zeichen »-« steht dabei für die leere Zeichenkette:\n[5.1 Wurzelknoten] - - -\n[5.2 Elementknoten] Name ohne Präfix URI des Namensraums, in dem sich das Element befindet voller Name\n[5.3 Attributknoten] Name ohne Präfix URI des Namensraums, in dem sich das Attribut befindet voller Name\n[5.4 Namensraumknoten] Namensraum-Präfix - Namensraum-Präfix\n[5.5 Processing-Instruction-Knoten] Ziel - Ziel\n[5.6 Kommentarknoten] - - -\n[5.7 Textknoten] - - -\nDiese Funktionen erwarten als Argument zwar eine Knotenmenge, werten jedoch immer nur den ersten Knoten bezüglich der Dokumentordnung aus. Der zugrunde liegende Begriff erweiterter Name wird in Kapitel [5 Datenmodell] erläutert.\nÜber den Umweg, den Namen eines Knotens auszuwerten, lassen sich Knotentests variabel beschreiben. Möchte man beispielsweise den Typ eines Nachkommenelements parametrisieren, kann man nicht descendant::$name verwenden. Mittels der Funktionen local-name und namespace-uri lässt sich das Problem lösen, indem zunächst alle Nachkommenelemente in die Ausgangsknotenmenge aufgenommen und anschließend innerhalb eines Prädikats diejenigen mit dem richtigen Namen und dem richtigen Namensraum herausgefiltert werden:\nFür XML-Dokumente, die keinen Gebrauch von Namensräumen machen, reicht bereits ein Vergleich mit der von der Funktion name gelieferten Zeichenkette.\nDie Funktion string konvertiert ein Objekt wie folgt in eine Zeichenkette:\nEine Knotenmenge wird in eine Zeichenkette konvertiert, indem der Zeichenkettenwert des ersten Knotens in Dokumentordnung zurückgegeben wird. Falls die Knotenmenge leer ist, wird eine leere Zeichenkette zurückgegeben.\nDer Zeichenkettenwert für jeden Knotentyp wird in Kapitel [5 Datenmodell] definiert. An dieser Stelle wird bereits zusammengefasst, welchen Wert die Funktion string abhängig vom jeweiligen Knotentyp zurückgibt.\n[5.1 Wurzelknoten] Zeichenkettenwert des Dokumentelements (des einzigen Kindes des Wurzelknotens)\n[5.2 Elementknoten] Verkettung der Zeichenkettenwerte aller Element- und Text-Kindknoten\n[5.3 Attributknoten] normalisierter Attributwert\n[5.4 Namensraumknoten] URI, d.h. Name des Namensraumes\n[5.5 Processing-Instruction-Knoten] Inhalt, der dem Ziel der Processing Instruction folgt\n[5.6 Kommentarknoten] Kommentarinhalt\n[5.7 Textknoten] enthaltene Zeichendaten\nNaN (Not a Number – keine gültige Zahl) wird in die Zeichenkette NaN konvertiert.\nPositiv Null wird in die Zeichenkette 0 konvertiert.\nNegativ Null wird in die Zeichenkette 0 konvertiert.\nPositiv unendlich wird in die Zeichenkette Infinity konvertiert.\nNegativ unendlich wird in die Zeichenkette -Infinity konvertiert.\nFalls die Zahl ein Integer ist, wird sie in dezimaler Form als Number dargestellt, ohne Dezimalpunkt und führende Nullen, mit negativem Vorzeichen (-), falls die Zahl negativ ist.\nAnsonsten wird die Zahl in Dezimalform als Number dargestellt, einschließlich Dezimalpunkt, wenigstens einer Ziffer vor und nach dem Dezimalpunkt sowie einem negativen Vorzeichen (-), falls die Zahl negativ ist. Es dürfen keine führenden Nullen vor dem Dezimalpunkt auftreten mit Ausnahme der eventuell erforderlichen Ziffer direkt vor dem Dezimalpunkt. Abgesehen von der einen erforderlichen Ziffer nach dem Dezimalpunkt müssen dort so viele, aber nicht mehr, Ziffern auftreten, wie zur eindeutigen Unterscheidung von allen anderen IEEE 754 numerischen Werten notwendig sind.\nDer boolesche Wert falsch wird in die Zeichenkette false konvertiert. Der boolesche Wert wahr wird in die Zeichenkette true konvertiert.\nDie Konvertierung eines Objekts von einem anderen Typ als den vier Grundtypen hängt von diesem Typ ab.\nWird kein Argument übergeben, wird stattdessen eine Knotenmenge mit dem Kontextknoten als einzigem Element benutzt.\nAnmerkung: Die Funktion string ist nicht dafür gedacht, Zahlen in Zeichenketten zu konvertieren, die an Nutzer ausgegeben werden. Die in [XSLT] definierte Funktion format-number und das ebenfalls dort definierte Element xsl:number stellen diese Funktionalität bereit.\nDie Funktion concat liefert die Verkettung ihrer Argumente.\nDie Funktion starts-with liefert den logischen Wert wahr, falls die im ersten Argument übergebene Zeichenkette mit der im zweiten Argument übergebenen Zeichenkette beginnt, und andernfalls falsch.\nDie Funktion contains liefert den logischen Wert wahr, falls die im ersten Argument übergebene Zeichenkette die im zweiten Argument übergebene Zeichenkette enthält, und andernfalls falsch.\nDie Funktion substring-before liefert aus der im ersten Argument übergebenen Zeichenkette die Teilzeichenkette, die vor dem ersten Auftreten der im zweiten Argument übergebenen Zeichenkette steht, bzw. die leere Zeichenkette, falls die erste Zeichenkette nicht die zweite enthält. Zum Beispiel liefert substring-before("1999/04/01","/") das Ergebnis 1999.\nDie Funktion substring-after liefert aus der im ersten Argument übergebenen Zeichenkette die Teilzeichenkette, die nach dem ersten Auftreten der im zweiten Argument übergebenen Zeichenkette steht, bzw. die leere Zeichenkette, falls die erste Zeichenkette nicht die zweite enthält. Zum Beispiel liefert substring-after("1999/04/01","/") das Ergebnis 04/01 und substring-after("1999/04/01","19") liefert 99/04/01.\nDie Funktion substring liefert aus der im ersten Argument übergebenen Zeichenkette die Teilzeichenkette, die an der im zweiten Argument angegebenen Position beginnt und die im dritten Argument angegebene Länge besitzt. Zum Beispiel liefert substring("12345",2,3) das Ergebnis "234". Falls kein drittes Argument angegeben wird, liefert die Funktion die Teilzeichenkette, die an der im zweiten Argument angegebenen Position beginnt und bis zum Ende der Zeichenkette reicht. Zum Beispiel liefert substring("12345",2) das Ergebnis "2345".\nGenauer gesagt wird für jedes Zeichen der Zeichenkette (siehe [3.6 Zeichenketten]) eine numerische Position angenommen: die Position des ersten Zeichens ist 1, die Position des zweiten Zeichens ist 2 usw.\nAnmerkung: Dies unterscheidet sich von Java und ECMAScript, in denen die Methode String.substring die Position des ersten Zeichens mit 0 definiert.\nDie zurückgegebene Teilzeichenkette enthält die Zeichen, deren Position größer oder gleich dem gerundeten Wert des zweiten Arguments ist und, falls ein drittes Argument übergeben wurde, kleiner als die Summe des gerundeten Wertes des zweiten und des gerundeten Wertes des dritten Arguments. Vergleich und Addition folgen den Standardregeln von IEEE 754; die Rundung erfolgt wie durch die Funktion round. Die folgenden Beispiele illustrieren einige unübliche Fälle:\nsubstring("12345", 1.5, 2.6) liefert "234"\nsubstring("12345", 0, 3) liefert "12"\nsubstring("12345", 0 div 0, 3) liefert ""\nsubstring("12345", 1, 0 div 0) liefert ""\nsubstring("12345", -42, 1 div 0) liefert "12345"\nsubstring("12345", -1 div 0, 1 div 0) liefert ""\nMit Hilfe eines ähnlich gearteten Aufrufs dieser Funktion können bedingte Ausdrücke für Zeichenketten und damit auch Zahlen simuliert werden. Ein bedingter Ausdruck liefert abhängig von der Auswertung eines logischen Ausdrucks einen von zwei möglichen vorgegebenen Werten. Für Knotenmengen wurde die analoge Funktionalität im Zusammenhang mit dem Vereinigungsoperator | bereits in Kapitel [3.3 Knotenmengen] vorgestellt.\nUnter Ausnutzung der Tatsache, dass ein logischer Wert wahr nach 1 und ein logischer Wert falsch nach 0 konvertiert wird (siehe Regeln bei der Funktion number), ergibt der Ausdruck\nden Wert string, falls boolean-test wahr ist, und ansonsten die leere Zeichenkette. Die vollständige Formulierung eines bedingten Ausdrucks sieht damit folgendermaßen aus:\nSolche Ausdrücke können beim Sortieren in XSLT eingesetzt werden, wenn der zu benutzende Sortierschlüssel von einer aktuell auszuwertenden Bedingung abhängt. Allerdings werden sie bei komplexeren Bedingungen schnell unübersichtlich.\nDie Funktion string-length liefert die Anzahl der Zeichen der Zeichenkette (siehe [3.6 Zeichenketten]). Falls kein Argument übergeben wurde, wird der in eine Zeichenkette konvertierte Kontextknoten angenommen, mit anderen Worten der Zeichenkettenwert des Kontextknotens.\nEs gibt in XPath keine Funktion ends-with, die analog zu starts-with bestimmt, ob eine Zeichenkette mit einer anderen endet. Mit Hilfe der Funktionen substring und string-length kann diese Funktionalität jedoch nachgebildet werden. ends-with($str1, $str2) würde den Wert wahr liefern, falls gilt:\nFür das Auffüllen einer Zeichenkette von links mit Leerzeichen (z.B. für eine rechtsbündige Textausgabe) erweisen sich die Funktionen concat, substring und string-length sowie eine ausreichend lange, ausschließlich aus Leerzeichen bestehende Zeichenkette als gute Helfer:\nDie Funktion normalize-space liefert als Ergebnis die übergebene Zeichenkette mit normalisiertem Leerraum zurück, d.h. führender und abschließender Leerraum werden entfernt, Folgen von mehreren Leerraumzeichen werden durch ein einzelnes Leerzeichen ersetzt. Leerraumzeichen sind jene, die durch die Produktion S in XML definiert sind. Falls kein Argument übergeben wurde, wird der in eine Zeichenkette konvertierte Kontextknoten angenommen, mit anderen Worten der Zeichenkettenwert des Kontextknotens.\nDiese Funktion verarbeitet eine übergebene Zeichenkette in der gleichen Weise, wie ein XML-Prozessor nach Ersetzung aller Referenzen Nicht-CDATA-Attribute behandelt, siehe Kapitel 3.3.3 in [XML, 2nd Edition].\nZur Erläuterung sei das folgende Beispiel angegeben. Häufig finden sich in XML-Dokumenten Textdaten, die folgendermaßen ausgezeichnet sind:\nDer Zeichenkettenwert des Elements name enthält neben der wichtigen Information über Otto Normal auch alle Leerraumzeichen, also den Zeilenumbruch nach dem Start-Tag <name>, die Leerzeichen vor Otto und den Zeilenumbruch inklusive eventueller Leerzeichen vor dem schließenden End-Tag. Ein Vergleich für den Kontextknoten name\nliefert also nicht das erhoffte Ergebnis, sondern schlägt fehl. Korrekt ist in diesem Fall stattdessen ein Vergleich mit dem normalisierten Wert des Knotens:\nAm Beispiel normalize-space soll an dieser Stelle vor einer Falle gewarnt werden, in die man bei der Übergabe von Knotenmengen an Funktionen mit skalaren Parametertypen leicht geraten kann. Angenommen, der Name Otto Normal kommt mehrfach vor und man möchte nur den ersten dieser name-Knoten bearbeiten. In diesem Fall kann man z.B. verlangen, dass keiner der Vorgänger den gleichen Namen hat. Ist eine Normalisierung nicht erforderlich, lautet der Test einfach:\nMuss man aber normalisieren, erweist sich der folgende Test als ungeeignet:\nDa die Funktion normalize-space als Argument eine Zeichenkette erwartet, wird die übergebene Knotenmenge mit der Funktion string konvertiert. Es wird also letztlich nur der erste Knoten (bezüglich der Dokumentordnung) der übergebenen Knotenmenge durch normalize-space ausgewertet und damit nur getestet, ob der erste name-Knoten einen von »Otto Normal« verschiedenen normalisierten Zeichenkettenwert besitzt. Die Lösung besteht in solchen Fällen darin, den Test in ein Prädikat zu verschieben:\nDie Funktion translate liefert als Ergebnis die im ersten Argument übergebene Zeichenkette, wobei jedes Vorkommen eines Zeichens aus der im zweiten Argument übergebenen Zeichenkette ersetzt wird durch das Zeichen an der korrespondierenden Position aus der im dritten Argument übergebenen Zeichenkette. Zum Beispiel liefert translate("bar","abc","ABC") die Zeichenkette BAr. Wenn es im zweiten Argument ein Zeichen gibt, für das kein korrespondierendes Zeichen im dritten Argument existiert (weil das zweite Argument länger ist als das dritte), so werden alle Vorkommen dieses Zeichens im ersten Argument entfernt. Zum Beispiel liefert translate("--aaa--","abc-","ABC") das Ergebnis "AAA". Falls ein Zeichen mehrmals im zweiten Argument vorkommt, bestimmt das erste Auftreten das Ersetzungszeichen. Falls die im dritten Argument übergebene Zeichenkette länger ist als die zweite, werden überzählige Zeichen ignoriert.\nAnmerkung: Die Funktion translate ist keine ausreichende Lösung für die Umwandlung zwischen Groß- und Kleinschreibung in allen Sprachen. Eine zukünftige Version von XPath kann zusätzliche Funktionen für diese Umwandlung zur Verfügung stellen.\nFür deutsche Umlaute reicht sie im Allgemeinen aus. Möchte man in einem Stylesheet an mehreren Stellen Klein- in Großschreibung umwandeln, bietet es sich an, geeignete Variablen zu definieren und fortan diese zu benutzen.\n<xsl:if test="translate(firma, $lower-case, $upper-case) = 'XYZ GMBH'">\nAllerdings stößt man schon beim Buchstaben »ß« an die Grenzen der Funktion translate. Die Ersetzung von »ß« durch die beiden Buchstaben »SS« ist auf diese Weise nicht möglich, weil der Ersetzungstext länger als ein Zeichen ist.\nAllgemein gilt, dass die Funktion translate kein Mittel zum Ersetzen von beliebigen Teilzeichenketten ist. Ein einmaliges Ersetzen im Sinne von replace($string, $from, $to) kann durch\nausgedrückt werden. XPath 1.0 stellt keine Mittel bereit, alle Vorkommen von $from in $string durch $to zu ersetzen. Dies wird sich in einer zukünftigen XPath-Version ändern [XPath Operators 2.0].\nMit der Funktion translate lassen sich darüber hinaus sehr einfach ausgewählte Zeichen aus einer Zeichenkette entfernen, indem als drittes Argument eine leere Zeichenkette übergeben wird. Dies kann beispielsweise für den Test genutzt werden, ob eine Zeichenkette $string nur die in $allowed-char aufgezählten Zeichen enthält:\nDie Funktion boolean konvertiert ihr Argument wie folgt in einen Boolean-Wert:\nEine Knotenmenge ergibt den Wert wahr genau dann, wenn sie nicht leer ist.\nAus diesem Grund lässt sich ein Test auf das Vorhandensein von Knoten sehr kompakt aufschreiben: img[@alt] bedeutet dasselbe wie img[boolean(@alt)]. Gesucht ist damit ein img-Element, das ein alt-Attribut besitzt.\nEine Zeichenkette ergibt genau dann den Wert wahr, wenn ihre Länge ungleich Null ist.\nZum Vergleich mit dem letzten Beispiel: img[string(@alt)] steht abkürzend für img[boolean(string(@alt))] und bedeutet jetzt, dass ein img-Element gesucht wird, dessen alt-Attribut einen nichtleeren Zeichenkettenwert besitzt. Für <img alt="" ... /> wäre der erste Test erfüllt, der zweite jedoch nicht.\nWährend das Argument der Funktionen string und number optional ist, beim Fehlen damit der Kontextknoten angenommen wird, ist das Argument für die Funktion boolean obligatorisch. Eine analoge Definition, die gegebenenfalls auf den Kontextknoten zurückgreift, hätte auch nicht viel Sinn, da in diesem Fall die Funktion boolean den Wert wahr liefern müsste – der Kontextknoten ist schließlich immer vorhanden.\nIm Unterschied zu den Operatoren and und or, die in den Produktionen OrExpr bzw. AndExpr definiert werden, handelt es sich bei not um eine Funktion.\nDie Funktion lang liefert einen Wert wahr oder falsch in Abhängigkeit davon, ob die durch xml:lang-Attribute angegebene Sprache des Kontextknotens die gleiche oder eine Untersprache der im Argument übergebenen Zeichenkette ist. Die Sprache des Kontextknotens wird durch den Wert des Attributes xml:lang des Kontextknotens bestimmt oder, wenn der Kontextknoten kein Attribut xml:lang besitzt, durch den Wert des Attributes xml:lang beim nächsten Vorfahren des Kontextknotens, der ein Attribut xml:lang besitzt. Wenn es kein solches Attribut gibt, liefert lang den Wert falsch. Wenn es ein solches Attribut gibt, liefert lang den Wert wahr, wenn der Attributwert gleich dem Argument ist, unabhängig von der Groß- oder Kleinschreibung, oder wenn es ein mit - beginnendes Suffix derart gibt, dass der Attributwert gleich dem Argument ohne dieses Suffix ist, unabhängig von der Groß- oder Kleinschreibung. Beispielsweise würde lang("en") den Wert wahr liefern, wenn es sich beim Kontextknoten um eines dieser fünf Elemente handelt:\nHandelt es sich beim Kontextknoten dagegen um das para-Element im Beispiel\n<div xml:lang="en"><sect xml:lang="de"><para/></sect></div>\nDas Verhalten der Funktion lang darf nicht mit einem impliziten Vorhandensein des Attributs xml:lang verwechselt werden. Für das obige Beispiel liefert //para[@xml:lang='de'] eine leere Knotenmenge, während //para[lang('de')] das para-Element auswählt.\nDie Funktion number konvertiert ihr Argument wie folgt in eine Zahl:\nEine Zeichenkette, die aus optionalem Leerraum besteht, gefolgt von einem optionalen Minuszeichen, gefolgt von einer Number, gefolgt von Leerraum, wird in eine IEEE-754-Zahl konvertiert, die (entsprechend den Rundungsregeln in IEEE 754) dem mathematischen Wert am nächsten ist, der durch die Zeichenkette repräsentiert wird. Jede andere Zeichenkette wird in NaN konvertiert.\nAnmerkung: Die Funktion number sollte nicht für die Konvertierung numerischer Daten in einem Element eines XML-Dokuments benutzt werden, es sei denn, das Element ist von einem Typ, der numerische Daten in einem sprachunabhängigen Format repräsentiert (das typischerweise für die Präsentation für einen Anwender in ein sprachspezifisches Format umgewandelt würde). Darüber hinaus kann die Funktion number nur genutzt werden, wenn das von dem Element genutzte sprachunabhängige Format mit der XPath-Syntax für Number konsistent ist.\nInsbesondere eignet sich eine Zahl im hiesigen Format (der Punkt zur Kennzeichnung der Tausenderstellen, das Komma zur Abgrenzung von den Dezimalstellen) nicht als Argument für die Funktion number. Der Aufruf von number('12.000,50') liefert beispielsweise den Wert NaN. Eine Umwandlung in das Format für Number kann in diesem Fall mit Hilfe der Funktion translate vorgenommen werden: number(translate('12.000,50', ',.', '.')).\nDie Funktion sum liefert die Summe aller in eine Zahl konvertierten Zeichenkettenwerte der Knoten aus der Argumentknotenmenge.\nSie eignet sich damit nur für Fälle, in denen die zu summierenden Werte direkt in der XML-Quelle vorliegen. Sollen die Summanden komplexer sein, d.h. jeweils durch einen eigenen Ausdruck berechnet werden, kann die Funktion sum nicht mehr benutzt werden. XPath nutzende Implementationen können aber eigene Sprachmittel bereitstellen, mit denen solche Berechnungen durchgeführt werden können.\nDie Funktion floor liefert die größte Zahl (die am nächsten an positiv unendlich liegt), die nicht größer als das Argument und ganzzahlig ist.\nWenn das Argument NaN ist, wird NaN zurückgegeben. Wenn das Argument positiv unendlich ist, wird positiv unendlich zurückgegeben. Wenn das Argument negativ unendlich ist, wird negativ unendlich zurückgegeben. Wenn das Argument positiv Null ist, wird positiv Null zurückgegeben. Wenn das Argument negativ Null ist, wird negativ Null zurückgegeben. Wenn das Argument größer als Null, aber kleiner als 1 ist, wird positiv Null zurückgegeben.\nDie Funktion ceiling liefert die kleinste Zahl (die am nächsten an negativ unendlich liegt), die nicht kleiner als das Argument und ganzzahlig ist.\nWenn das Argument NaN ist, wird NaN zurückgegeben. Wenn das Argument positiv unendlich ist, wird positiv unendlich zurückgegeben. Wenn das Argument negativ unendlich ist, wird negativ unendlich zurückgegeben. Wenn das Argument positiv Null ist, wird positiv Null zurückgegeben. Wenn das Argument negativ Null ist, wird negativ Null zurückgegeben. Wenn das Argument kleiner als Null, aber größer als -1 ist, wird positiv Null zurückgegeben.\nDie Funktion round liefert die Zahl, die am nächsten am Argument liegt und die ganzzahlig ist. Wenn es zwei solche Zahlen gibt, wird die Zahl geliefert, die näher an positiv unendlich liegt. Ist das Argument NaN, wird NaN zurückgegeben. Ist das Argument positiv unendlich, wird positiv unendlich zurückgegeben. Ist das Argument negativ unendlich, wird negativ unendlich zurückgegeben. Ist das Argument positiv Null, wird positiv Null zurückgegeben. Ist das Argument negativ Null, wird negativ Null zurückgegeben. Ist das Argument kleiner als Null, aber größer oder gleich -0.5, wird negativ Null zurückgegeben.\nAnmerkung: In den letzten beiden Fällen ist das Ergebnis des Aufrufs der Funktion round verschieden von der Addition von 0.5 und dem Aufruf der Funktion floor.\nXPath operiert auf der Baumrepräsentation eines XML-Dokuments. Das folgende Kapitel beschreibt, wie XPath ein XML-Dokument als Baum modelliert. Dieses Modell ist rein konzeptionell und schreibt keinerlei spezielle Implementation vor. Die Beziehung zwischen diesem Modell und der XML-Informationsmenge [XML Infoset] wird in [B Abbildung auf die XML-Informationsmenge] beschrieben.\nDie durch XPath verarbeiteten XML-Dokumente müssen sich nach der XML-Namensraum-Empfehlung [XML Names] richten.\nInsbesondere dürfen Namen von Elementen und Attributen das Zeichen »:« nur als Separator zwischen Namensraum-Präfix und lokalem Namen enthalten. Außerdem muss jedes benutzte Präfix deklariert worden sein. XML-Dokumente, die den Doppelpunkt nicht Namensraum-konform verwenden, können durch XPath-Implementationen nicht verarbeitet werden.\nFür jeden Knotentyp gibt es einen Weg, den Zeichenkettenwert eines Knotens dieses Typs zu bestimmen. Bei einigen Knotentypen ist der Zeichenkettenwert Teil des Knotens, bei anderen Knotentypen wird der Zeichenkettenwert aus den Zeichenkettenwerten der Nachkommen berechnet.\nAnmerkung: Für Element- und Wurzelknoten ist der Zeichenkettenwert eines Knotens verschieden von der Zeichenkette, die von der DOM-Methode nodeValue zurückgegeben wird (siehe [DOM]).\nEinige Knotentypen besitzen außerdem einen erweiterten Namen – ein Paar bestehend aus einem lokalen Teil und einem Namensraum-URI. Der lokale Teil ist eine Zeichenkette. Der Namensraum-URI ist entweder leer oder eine Zeichenkette. Der im XML-Dokument spezifizierte Namensraum-URI kann eine URI-Referenz sein, wie sie in [RFC2396] definiert ist; das bedeutet, sie kann einen Fragment-Bezeichner besitzen und sie kann relativ sein. Ein relativer URI sollte als absoluter URI während der Namensraum-Verarbeitung aufgelöst werden: Die Namensraum-URIs der erweiterten Namen von Knoten im Datenmodell sollten absolut sein. Zwei erweiterte Namen sind gleich, wenn sie den gleichen lokalen Teil haben und wenn beide einen leeren Namensraum-URI oder beide die gleichen, nichtleeren Namensraum-URIs besitzen.\nNach einer Entscheidung des W3C-XML-Plenums ist die Behandlung relativer Namensraum-URIs implementationsabhängig. Gemäß Errata-Dokument [XPath Errata] müssen deshalb aus dem obigen Abschnitt die Sätze "Der im XML-Dokument spezifizierte Namensraum-URI kann eine URI-Referenz sein, wie sie in [RFC2396] definiert ist; das bedeutet, sie kann einen Fragment-Bezeichner besitzen und sie kann relativ sein. Ein relativer URI sollte als absoluter URI während der Namensraum-Verarbeitung aufgelöst werden: Die Namensraum-URIs der erweiterten Namen von Knoten im Datenmodell sollten absolut sein." ersetzt werden durch:\nEin in einer Namensraumdeklaration spezifizierter Namensraum-Name in einem XML-Dokument ist eine URI-Referenz, wie sie in [RFC2396] definiert ist; das bedeutet, sie kann einen Fragment-Bezeichner besitzen und sie kann relativ sein. Die Namensraum-URI-Komponente eines erweiterten Namens ist implementationsabhängig, wenn der erweiterte Name aus einem QName expandiert wird, dessen Präfix durch eine Namensraumdeklaration mit einem relativen URI (mit oder ohne Fragment-Bezeichner) als Namensraum-Namen deklariert wurde. Ein XPath-Ausdruck, der vom Wert der Namensraum-URI-Komponente eines solchen erweiterten Namens abhängt, ist nicht interoperabel.\nRelative URIs der Form »host.example.org/namespace« (fehlendes Schema), »home/schema« (fehlende Host-Angabe), »http://www.w3.org/1999/../2001/XMLSchema« (mit speziellen Pfadkomponenten) oder »http://www.schema.org/address#one« (mit Fragment-Bezeichner) sollten damit vermieden werden.\nEs existiert eine Ordnung, die Dokumentordnung, die für alle Knoten im Dokument definiert ist und die zu der Ordnung korrespondiert, in der die ersten Zeichen der XML-Repräsentation aller Knoten in der XML-Repräsentation des Dokuments nach der Expandierung allgemeiner Entities stehen. Der Wurzelknoten ist demzufolge der erste Knoten. Elementknoten stehen vor ihren Kindern. Das bedeutet, die Dokumentordnung ordnet Elementknoten in der Reihenfolge ihrer Start-Tags im XML-Dokument (nach der Expandierung von Entities). Attribut- und Namensraumknoten eines Elements kommen vor den Kindern des Elements. Namensraumknoten erscheinen per Definition vor den Attributknoten. Die relative Ordnung innerhalb der Namensraumknoten ist implementationsabhängig. Die relative Ordnung innerhalb der Attributknoten ist implementationsabhängig. Die umgekehrte Dokumentordnung ist die Umkehrung der Dokumentordnung.\nMan darf an dieser Stelle nicht vergessen, dass die Elemente einer Knotenmenge trotzdem immer ungeordnet sind. Die Eigenschaft, die Knoten einer Menge in einer bestimmten Reihenfolge zu betrachten, gehört immer zu einer Operation oder Funktion, die auf dieser Menge ausgeführt wird. So konvertieren die Funktionen string, boolean und number bei einer gegebenen Knotenmenge immer den ersten Knoten bezüglich der Dokumentordnung. Entsprechend legen auf Ausdrücke angewandte Prädikate immer die Dokumentordnung zugrunde. Demgegenüber legt innerhalb eines Lokalisierungsschrittes immer die jeweilige Achse die für die dazugehörenden Prädikate relevante Ordnung fest. Nachdem eine Knotenmenge konstruiert wurde, ist sie (wieder) ungeordnet. Siehe dazu auch die entsprechende Anmerkung in Kapitel [3.3 Knotenmengen].\nWurzel- und Elementknoten besitzen eine geordnete Liste von Kindknoten. Mehrere Knoten haben niemals gemeinsame Kinder: Wenn ein Knoten von einem anderen Knoten verschieden ist, dann ist kein Kindknoten des einen Knotens mit einem der Kindknoten des anderen Knotens identisch. Jeder Knoten mit Ausnahme des Wurzelknotens besitzt genau einen Elternknoten, wobei dieser entweder ein Elementknoten oder der Wurzelknoten ist. Ein Wurzel- oder ein Elementknoten ist der Elternknoten jedes seiner Kindknoten. Die Nachkommen eines Knotens sind die Kinder des Knotens sowie die Nachkommen der Kinder des Knotens.\nDie Bezeichnungen Eltern- und Kindknoten sind vielleicht nicht ganz glücklich. Jeder Knoten besitzt nämlich maximal einen Elternknoten. Daneben sind Attribut- und Namensraumknoten vergleichbar mit rebellierenden Teenagern, die im XPath-Datenmodell nicht als Kinder ihrer Element-Elternknoten betrachtet werden.\nDer Wurzelknoten ist die Wurzel des Baumes. Ein Wurzelknoten kommt nur als Wurzel des Baumes vor. Der Elementknoten für das Dokumentelement ist ein Kind des Wurzelknotens. Der Wurzelknoten hat als Kinder ebenfalls Processing-Instruction-Knoten und Kommentarknoten für Processing Instructions und Kommentare, die im Prolog oder hinter dem Ende des Dokumentelements auftreten.\nDie Dokumenttyp-Deklaration ist kein Kind des Wurzelknotens. Sie kommt als solche an keiner Stelle im XPath-Datenmodell vor. So kann ein XSLT-Stylesheet keine Kopie der Dokumenttyp-Deklaration erzeugen. Ebenso werden innerhalb der Dokumenttyp-Deklaration auftretende Kommentare oder Processing Instructions nicht durch XPath-Knoten repräsentiert.\nDer Zeichenkettenwert des Wurzelknotens ergibt sich aus der Verkettung der Zeichenkettenwerte aller Textknoten in Dokumentordnung, die Nachkommen des Wurzelknotens sind.\nDa außerhalb des Dokumentelements keine Textknoten auftreten dürfen, gilt also\noder mit anderen Worten: Der Wurzelknoten und sein (einziger) Element-Kindknoten besitzen den gleichen Zeichenkettenwert. Diesen erhält man auch, wenn aus dem Eingabedokument jegliches Markup entfernt und nur die Zeichendaten behalten werden.\nDas bedeutet, dass die Funktionen name, local-name und namespace-uri als Ergebnis die leere Zeichenkette liefern. Das in DOM definierte Attribut nodeName besitzt dagegen für das Document-Objekt als Wert die Zeichenkette »#document«.\nFür jedes Element im Dokument gibt es einen Elementknoten. Ein Elementknoten besitzt einen erweiterten Namen, der sich durch Expandierung des im Tag des Elements spezifizierten QName in Übereinstimmung mit der XML-Namensraum-Empfehlung [XML Names] ergibt. Der Namensraum-URI des erweiterten Namens des Elements ist leer, wenn der QName kein Präfix enthält und es keinen anwendbaren voreingestellten Namensraum gibt.\nAnmerkung: In der im Anhang A.3 von [XML Names] verwendeten Notation entspricht der lokale Teil des erweiterten Namens dem Attribut type des Elements ExpEType; der Namensraum-URI des erweiterten Namens entspricht dem Attribut ns des Elements ExpEType und ist leer, wenn das Attribut ns des Elements ExpEType weggelassen wurde.\nDie Kinder eines Elementknotens sind die enthaltenen Elementknoten, Kommentarknoten, Processing-Instruction-Knoten und Textknoten. Entity-Referenzen zu internen und externen Entities werden expandiert. Zeichenreferenzen werden aufgelöst.\nDer Zeichenkettenwert eines Elementknotens ergibt sich aus der Verkettung der Zeichenkettenwerte aller Textknoten, die Nachkommen des Elementknotens in Dokumentordnung sind.\nDamit gilt, dass der Zeichenkettenwert eines Elementknotens genauso als Verkettung der Zeichenkettenwerte seiner Element- und Textkinder in Dokumentordnung aufgefasst werden kann.\nEin Elementknoten kann einen eindeutigen Bezeichner (ID) besitzen. Dies ist der Wert des Attributes, das in der DTD mit dem Typ ID deklariert wurde. Keine zwei Elemente in einem Dokument dürfen den gleichen eindeutigen Bezeichner besitzen. Falls ein XML-Prozessor zwei Elemente in einem Dokument mit dem gleichen eindeutigen Bezeichner meldet (was nur möglich ist, wenn das Dokument ungültig ist), dann muss das zweite Element in Dokumentordnung so behandelt werden, als habe es keinen eindeutigen Bezeichner.\nAnmerkung: Wenn ein Dokument keine DTD besitzt, dann hat kein Element des Dokuments einen eindeutigen Bezeichner.\nFür zwei oder mehr Elemente mit dem gleichen eindeutigen Bezeichner liefert die Funktion id nur den ersten Elementknoten in Dokumentordnung zurück. Da die Eigenschaft eines Attributes, eindeutiger Bezeichner zu sein, in der DTD deklariert wird, kann ohne DTD dieses Attribut nicht mehr erkannt werden. Das bedeutet, dass die Funktion id nach dem Entfernen der DTD aus dem Eingabedokument für jedes Argument nur noch die leere Knotenmenge liefert. Dies ist einer der wenigen Fälle, in denen die Existenz einer DTD sich auf die Auswertung eines XPath-Ausdrucks auswirkt.\nJedes Element besitzt eine mit ihm verbundene Menge von Attributknoten; das Element ist der Elternknoten jedes dieser Attributknoten. Allerdings ist ein Attributknoten kein Kind seines Elternknotens.\nAnmerkung: Dies unterscheidet sich vom DOM, welches ein Element nicht als Elternknoten seiner Attribute behandelt (siehe [DOM]).\nMehrere Elemente haben niemals gemeinsame Attributknoten: Wenn ein Elementknoten verschieden von einem anderen Elementknoten ist, dann ist kein Attributknoten des einen Elementknotens mit einem der Attributknoten eines anderen Elementknotens identisch.\nAnmerkung: Der Operator = testet, ob zwei Knoten den gleichen Wert haben, nicht ob es dieselben Knoten sind. Vergleicht man die Attribute von zwei verschiedenen Elementen mittels =, so kann sich Gleichheit ergeben, obwohl diese nicht dieselben Knoten sind.\nWert bedeutet hier wieder Zeichenkettenwert. Tatsächlich gilt die obige Anmerkung für alle Knoten, nicht nur für Attribute. Um die Identität zweier Knoten zu überprüfen, kann man sich beispielsweise der in Kapitel [3.3 Knotenmengen] im Zusammenhang mit dem Operator | vorgestellten Technik bedienen.\nEin vorgegebenes Attribut wird genauso behandelt wie ein spezifiziertes Attribut. Falls für einen Elementtyp ein Attribut in der DTD deklariert wurde, der Vorgabewert jedoch als #IMPLIED deklariert und das Attribut für das Element nicht angegeben wurde, so enthält die Attributmenge des Elements keinen Knoten für dieses Attribut.\n<!DOCTYPE see [\n<!ATTLIST see access (public|restricted) "public"\nref    CDATA               #IMPLIED >\nIn diesem Fall besitzt der einzige Elementknoten see im XPath-Datenmodell genau einen Attributknoten namens access mit dem Wert public. Im Gegensatz zu ref handelt es sich bei access um ein vorgegebenes Attribut.\nDas XPath-Datenmodell liefert keinerlei Informationen darüber, ob ein solches Attribut im Start-Tag eines Elements spezifiziert wurde oder nicht. Im zweiten Fall ändert sich im Falle des Entfernens der DTD die Baumrepräsentation des XML-Dokuments, da alle vorgegebenen, aber nicht spezifizierten Attribute wegfallen.\nEinige Attribute, wie xml:lang und xml:space, besitzen die Semantik, dass sie für alle Elemente gelten, die Nachkommen des Elements sind, das das Attribut trägt, es sei denn, sie wurden in einer Instanz eines Nachkommenelements durch das gleiche Attribut überschrieben. Das wirkt sich allerdings nicht darauf aus, wo Attributknoten im Baum vorkommen: Ein Element besitzt nur Attributknoten für die Attribute, die explizit im Start-Tag oder Leeres-Element-Tag dieses Elements angegeben wurden oder die in der DTD explizit mit einem Vorgabewert deklariert wurden.\nIm Zusammenhang mit der Funktion lang wurde auf diese Eigenschaft bereits hingewiesen. Ein Attribut xml:lang wirkt sich zwar semantisch auf die Nachkommen aus, allerdings erscheint es nicht implizit als Attributknoten bei diesen Nachkommen.\nDamit liefert z.B. //*[lang('de')] in der Regel eine andere Knotenmenge als //*[@xml:lang='de']. Im ersten Ausdruck werden alle die Knoten ausgewählt, für die selbst oder für deren nächsten Vorfahren die Sprache Deutsch (de) festgelegt wurde. Der zweite Ausdruck wählt dagegen nur die Knoten aus, die ein Attribut xml:lang explizit oder als Vorgabewert mit dem Wert de besitzen. Abgesehen davon würde die zweite Variante auch Attribute wie xml:lang="DE-CH" unberücksichtigt lassen.\nEin Attributknoten hat einen erweiterten Namen und einen Zeichenkettenwert. Der erweiterte Name wird durch Expandierung des im Tag im XML-Dokument angegebenen QName in Übereinstimmung mit der XML-Namensraum-Empfehlung [XML Names] berechnet. Der Namensraum-URI des Attributnamens ist leer, falls der QName des Attributs kein Präfix enthält.\nEntsprechend der XML-Namensraum-Empfehlung [XML Names] wirkt sich somit ein voreingestellter Namensraum im Gegensatz zu Elementknoten nicht auf Attribute ohne Präfix aus.\nAnmerkung: In der im Anhang A.3 von [XML Names] verwendeten Notation entspricht der lokale Teil des erweiterten Namens dem Attribut name des Elements ExpAName; der Namensraum-URI des erweiterten Namens entspricht dem Attribut ns des Elements ExpAName und ist leer, wenn das Attribut ns des Elements ExpAName weggelassen wurde.\nEin Attributknoten besitzt einen Zeichenkettenwert. Dieser Zeichenkettenwert ist der durch die XML-Empfehlung [XML] spezifizierte normalisierte Wert. Ein Attribut, dessen normalisierter Wert eine Zeichenkette der Länge null ist, wird nicht gesondert behandelt: Es resultiert in einem Attributknoten, dessen Zeichenkettenwert eine Zeichenkette der Länge null ist.\nNormalisierung bedeutet, dass alle Entity- und Zeichenreferenzen aufgelöst sowie alle Leerraumzeichen durch die gleiche Anzahl Leerzeichen ersetzt werden. Ist der Attributtyp nicht CDATA, wird der Attributwert darüber hinaus wie bei der Anwendung der Funktion normalize-space umgewandelt.\nAnmerkung: Es ist möglich, dass Attribute mit Vorgabewerten in einer externen DTD oder einem externen Parameter-Entity deklariert werden. Die XML-Empfehlung verlangt nicht, dass ein XML-Prozessor eine externe DTD oder ein externes Parameter-Entity einliest, es sei denn, dieser ist validierend. Ein Stylesheet oder ein anderes Werkzeug, das annimmt, der XPath-Baum enthalte in einer externen DTD oder einem externen Parameter-Entity deklarierte Vorgabewerte, kann möglicherweise mit nicht-validierenden XML-Prozessoren nicht funktionieren.\nEs gibt keine Attributknoten zu Attributen, die Namensräume deklarieren (siehe [XML Names]).\nAttribute mit dem Namen »xmlns« oder dem Präfix »xmlns« werden nicht als Attributknoten, sondern als Namensraumknoten im Datenmodell repräsentiert.\nJedem Element ist eine Menge von Namensraumknoten zugeordnet, einer für jedes einzelne Namensraum-Präfix, das für das Element gültig ist (einschließlich des Präfixes xml, das implizit durch die XML-Namensraum-Empfehlung deklariert wird) und einer für den voreingestellten Namensraum, falls einer für das Element gültig ist. Das Element ist der Elternknoten jedes dieser Namensraumknoten; ein Namensraumknoten ist allerdings kein Kind seines Elternelements. Mehrere Elemente haben niemals gemeinsame Namensraumknoten: Wenn ein Elementknoten verschieden von einem anderen Elementknoten ist, dann ist kein Namensraumknoten des einen Elementknotens mit einem der Namensraumknoten eines anderen Elementknotens identisch. Das bedeutet, ein Element besitzt einen Namensraumknoten:\nfür jedes Attribut des Elements, dessen Name mit xmlns: beginnt;\nfür jedes Attribut eines Vorfahrenelements, dessen Name mit xmlns: beginnt, es sei denn, das Element selbst oder ein näherer Vorfahre deklariert das Präfix um;\nfür ein xmlns-Attribut, falls das Element oder ein Vorfahre ein xmlns-Attribut besitzt und der Wert des xmlns-Attributs beim nächsten dieser Elemente nicht leer ist.\nAnmerkung: Ein Attribut xmlns="" "undeklariert" den voreingestellten Namensraum (siehe [XML Names]).\nNamensraumdeklarationen wirken sich damit in der Regel auf die Nachkommen des Elements aus, in dem diese Deklaration erscheint. Im Gegensatz zu den Attributen xml:lang und xml:space werden Namensraumknoten jedoch tatsächlich an die Nachkommen vererbt. Jeder Elementknoten besitzt ein eigenes Knoten-Exemplar für jeden gültigen Namensraum.\nWie bereits in Kapitel [1 Einleitung] an einem Beispiel verdeutlicht wurde, folgt aus der Namensraum-Empfehlung, dass jedes Element wenigstens einen Namensraumknoten mit dem Präfix xml und dem Namensraum-URI http://www.w3.org/XML/1998/namespace besitzt.\n<foo:e1 xmlns:foo="bar"><foo:e2 /></foo:e1>\n<foo:e1 xmlns:foo="bar"><foo:e2 xmlns:foo="bar" /></foo:e1>\nEin Namensraumknoten besitzt einen erweiterten Namen: Der lokale Teil ist das Namensraum-Präfix (dieses ist leer, falls der Namensraumknoten den voreingestellten Namensraum repräsentiert); der Namensraum-URI ist immer leer.\nDer Zeichenkettenwert eines Namensraumknotens ist der Namensraum-URI, der an das Namensraum-Präfix gebunden ist. Wenn dieser relativ ist, muss er wie ein Namensraum-URI in einem erweiterten Namen aufgelöst werden.\nNach einer Entscheidung des W3C-XML-Plenums ist die Behandlung relativer Namensraum-URIs implementationsabhängig. Gemäß Errata-Dokument [XPath Errata] muss dieser letzte Absatz durch den folgenden ersetzt werden:\nDer Zeichenkettenwert eines Namensraumknotens ist der Namensraum-URI, der an das Namensraum-Präfix gebunden ist; wenn der in der Namensraumdeklaration auftretende Namensraum-Name ein relativer URI (mit oder ohne Fragment-Bezeichner) ist, so ist der Zeichenkettenwert implementationsabhängig. Ein XPath-Ausdruck, der vom Zeichenkettenwert eines solchen Namensraumknotens abhängt, ist nicht interoperabel.\nDie Definition des erweiterten Namens für Namensraumknoten mag auf den ersten Blick etwas ungewöhnlich erscheinen. Tatsächlich wurde hier das Namensraum-Präfix als eigentlich relevanter Namensbestandteil dem Schema für erweiterte Namen angepasst, den jeder Knoten besitzt. Der Namensraum-URI des Namens ist leer, da der Name eines Namensraumknotens nicht von anderen gültigen Namensraumdeklarationen abhängt.\nZur Illustration zwei Beispiele: Die Deklaration xmlns:prefix="urn:eindeutiger-bezeichner" erzeugt einen Namensraumknoten, dessen erweiterter Name gleich [»prefix«, »«] ist. Eine Deklaration für den voreingestellten Namensraum xmlns="urn:eindeutiger-bezeichner" führt zu einem Knoten mit dem erweiterten Namen [»«, »«]. Der Zeichenkettenwert ist in beiden Fällen »urn:eindeutiger-bezeichner«. Ein Namensraumknoten hat niemals einen leeren Zeichenkettenwert.\nNamensraumknoten werden benötigt, wenn in den Daten enthaltene qualifizierte Namen ausgewertet werden sollen. Die Typangabe in einem XML-Schema ist so ein Beispiel: type="ob:adresse". Zur Ermittlung des dazugehörigen Namensraum-URIs kann folgender Ausdruck verwendet werden:\n<?xml-stylesheet href='style.xsl' title='Hauptstylesheet'?>\nwird z.B. durch einen Knoten repräsentiert, dessen erweiterter Name [»xml-stylesheet«, »«] und dessen Zeichenkettenwert »href='style.xsl' title='Hauptstylesheet'« ist.\nFür jeden Kommentar gibt es einen Kommentarknoten, mit Ausnahme der Kommentare, die innerhalb der Dokumenttyp-Deklaration erscheinen.\nDer Zeichenkettenwert eines Kommentarknotens ist der Inhalt des Kommentars ohne die öffnenden Zeichen <!-- und die schließenden Zeichen -->.\nZeichendaten werden in Textknoten zusammengefasst. Dabei werden so viele Zeichen wie möglich in jedem Textknoten zusammengefasst: Ein Textknoten hat niemals als direkten Vorgänger oder Nachfolger einen anderen Textknoten. Der Zeichenkettenwert eines Textknotens besteht aus den Zeichendaten. Ein Textknoten enthält immer wenigstens ein Zeichen.\nJedes Zeichen innerhalb eines CDATA-Abschnittes wird wie Zeichendaten behandelt. So wird <![CDATA[<]]> im Quelldokument genauso behandelt wie <. Beides ergibt das einzelne Zeichen < in einem Textknoten innerhalb des Baumes. Ein CDATA-Abschnitt wird damit so behandelt, als würden <![CDATA[ und ]]> entfernt und jedes Vorkommen von < und & durch < bzw. & ersetzt werden.\nDas XPath-Datenmodell enthält also keinerlei Informationen darüber, in welcher Form ein Zeichen innerhalb des XML-Dokuments repräsentiert war. Die folgenden Textinhalte des Elements x werden alle auf den gleichen Textknoten mit dem Inhalt »A« abgebildet:\nEntsprechend würde beispielsweise der Inhalt des folgenden Elements para in einem einzigen Textknoten zusammengefasst werden. Der Beginn des CDATA-Abschnittes kann in XPath nicht bestimmt werden. Das Document Object Model [DOM] sieht hier stattdessen spezielle Objekte Text und CDATASection vor.\nHier folgen Beispiel & Erklärung:\n<![CDATA[a > 10 and a < 20]]> bedeutet ...\nEinzelne Zeichendaten werden innerhalb des Datenmodells nicht separat repräsentiert. Zur Verarbeitung muss deshalb auf die bereitgestellten Zeichenkettenfunktionen zurückgegriffen werden.\nAnmerkung: Wird ein Textknoten, der das Zeichen < enthält, als XML ausgegeben, so muss das Zeichen < geschützt werden, beispielsweise durch < oder durch Einschluss in einen CDATA-Abschnitt.\nZeichen innerhalb von Kommentaren, Processing Instructions und Attributwerten erzeugen keine Textknoten. Zeilenenden in externen Entities werden zu #xA normalisiert, so wie in der XML-Empfehlung [XML] spezifiziert.\nGenau genommen lässt sich durch XPath nicht beeinflussen, ob Leerraum generell Textknoten erzeugen soll. Abhängig von der Applikation, die XPath verwendet, werden für ausschließlich aus Leerraum bestehende Bereiche Textknoten angelegt oder nicht. Die Illustration zum Beispiel in Kapitel [1 Einleitung] beruht auf der Annahme, dass solche Leerraum-Textknoten vorhanden sind. Das ist auch das Standardverhalten in XSLT [XSLT] für zu verarbeitende XML-Dokumente. Durch Verwendung der XSLT-Elemente xsl:strip-space und xsl:preserve-space lässt sich dieses Verhalten allerdings beeinflussen. Darüber hinaus werden Leerraum-Textknoten, die als Kind eines Elements mit xml:space="preserve" (siehe [XML, 2nd Edition]) auftreten, niemals entfernt.\nDie Existenz solcher Leerraum-Textknoten kann sich auf Kontextgröße und -position und damit auf das Ergebnis der Funktionen last, position und count auswirken. Die Berechnung des Ausdrucks name/text() für das folgende Beispiel hängt entscheidend davon ab, ob Leerraum-Textknoten mitgezählt werden oder nicht:\nDas bedeutet, dass die Funktionen name, local-name und namespace-uri als Ergebnis die leere Zeichenkette liefern. Das in DOM definierte Attribut nodeName besitzt dagegen für Text-Objekte als Wert die Zeichenkette »#text« und für CDATASection-Objekte den Wert »#cdata-section«.\nXPath ist in erster Linie als Komponente gedacht, die von anderen Spezifikationen genutzt werden kann. Demzufolge überlässt es XPath den Spezifikationen, die XPath nutzen (etwa [XPointer] und [XSLT]), Kriterien für die Konformität von XPath zu spezifizieren und definiert selbst keinerlei Konformitätskriterien für unabhängige XPath-Implementationen.\nDie Organisation Oasis hat eine Kommission für die Konformität von XSLT- und XPath-Implementationen [XSLT-Konformität] gebildet, die geeignete Szenarien für eine Test-Suite zusammenstellt.\nInstitute of Electrical and Electronics Engineers: IEEE Standard for Binary Floating-Point Arithmetic. ANSI/IEEE Std 754-1985.\nT. Berners-Lee, R. Fielding und L. Masinter: Uniform Resource Identifiers (URI): Generic Syntax. IETF RFC 2396. Siehe http://www.ietf.org/rfc/rfc2396.txt.\nWorld Wide Web Consortium: Extensible Markup Language (XML) 1.0. W3C Recommendation. Siehe http://www.edition-w3c.de/TR/1998/REC-xml-19980210.\nWorld Wide Web Consortium: Namespaces in XML. W3C Recommendation. Siehe http://www.edition-w3c.de/TR/REC-xml-names.\nWorld Wide Web Consortium: Character Model for the World Wide Web. W3C Working Draft. Siehe http://www.edition-w3c.de/TR/WD-charmod.\nWorld Wide Web Consortium: Document Object Model (DOM) Level 1 Specification. W3C Recommendation. Siehe http://www.edition-w3c.de/TR/REC-DOM-Level-1.\nJ. Gosling, B. Joy und G. Steele: The Java Language Specification. Siehe http://java.sun.com/docs/books/jls/index.html.\nISO (International Organization for Standardization): ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane. Internationaler Standard. Siehe http://www.iso.ch/cate/d18741.html.\nC.M. Sperberg-McQueen und L. Burnard: Guidelines for Electronic Text Encoding and Interchange. Siehe http://etext.virginia.edu/TEI.html.\nUnicode Consortium: The Unicode Standard. Siehe http://www.unicode.org/unicode/standard/standard.html.\nWorld Wide Web Consortium: XML Pointer Language (XPointer). W3C Working Draft. Siehe http://www.edition-w3c.de/TR/WD-xptr.\nJ. Robie, J. Lapp und D. Schach: XML Query Language (XQL). Siehe http://www.w3.org/TandS/QL/QL98/pp/xql.html.\nWorld Wide Web Consortium: XSL Transformations (XSLT). W3C Recommendation. Siehe http://www.edition-w3c.de/TR/xslt.\nDie Knoten im XPath-Datenmodell lassen sich aus den durch die XML-Informationsmenge [XML Infoset] bereitgestellten Informationseinheiten wie folgt ableiten.\nAnmerkung: Eine neue Version des Arbeitsentwurfs der XML-Informationsmenge, die die Version vom 17. Mai (1999, der Übersetzer) ersetzen wird, war zu der Zeit, als die Vorbereitung dieser Version der XPath-Spezifikation vollendet wurde, kurz vor der Fertigstellung. Ihre Veröffentlichung wurde zur gleichen Zeit oder kurz nach Veröffentlichung dieser Version von XPath erwartet. Die Abbildung wird für diese neue Version des Arbeitsentwurfs der XML-Informationsmenge angegeben. Falls die neue Version des Arbeitsentwurfs der XML-Informationsmenge noch nicht veröffentlicht worden sein sollte, können W3C-Mitglieder die interne Arbeitsgruppenversion http://www.w3.org/XML/Group/1999/09/WD-xml-infoset-19990915.html (nur für Mitglieder) einsehen.\nDie XML-Informationsmenge beschreibt die aus einem XML-Dokument ableitbaren Informationen auf einer abstrakten Ebene. Zu diesem Zweck wurden elf Typen, so genannte Informationseinheiten (information items) definiert. Jede dieser Informationseinheiten besitzt eine Reihe von Eigenschaften (properties). Es wurde in der XML-Informationsmenge bewusst nicht der Term "Knoten" verwendet, um Verwechslungen mit DOM- und XPath-Knoten zu vermeiden. Die im XPath-Datenmodell definierten Knotentypen beschreiben eine Teilmenge der in der XML-Informationsmenge verfügbaren Informationen und lassen sich daher aus diesen Informationseinheiten ableiten.\nDie Eigenschaft children - comments gibt es nicht mehr. Stattdessen folgen mögliche Kommentar-Kindknoten des Wurzelknotens ebenfalls unmittelbar aus der Eigenschaft children.\nEin Elementknoten folgt aus einer Element-Informationseinheit. Die Kinder eines Elementknotens folgen aus den Eigenschaften children und children - comments. Die Attribute eines Elementknotens folgen aus der Eigenschaft attributes. Die Namensräume eines Elementknotens folgen aus der Eigenschaft in-scope namespaces. Der lokale Teil des erweiterten Namens eines Elementknotens folgt aus der Eigenschaft local name. Der Namensraum-URI des erweiterten Namens eines Elementknotens folgt aus der Eigenschaft namespace URI. Der eindeutige Bezeichner (ID) eines Elementknotens folgt aus der Eigenschaft children der Attribut-Informationseinheit in der Eigenschaft attributes, deren Eigenschaft attribute type gleich ID ist.\nDie Eigenschaft children - comments gibt es nicht mehr. Stattdessen folgen mögliche Kommentar-Kindknoten eines Elementknotens ebenfalls unmittelbar aus der Eigenschaft children. Der Namensraum-URI des erweiterten Namens eines Elementknotens folgt aus der Eigenschaft namespace name. Der eindeutige Bezeichner (ID) eines Elementknotens folgt aus der Eigenschaft normalized value der Attribut-Informationseinheit in der Eigenschaft attributes, deren Eigenschaft attribute type gleich ID ist.\nEin Attributknoten folgt aus einer Attribut-Informationseinheit. Der lokale Teil des erweiterten Namens des Attributknotens folgt aus der Eigenschaft local name. Der Namensraum-URI des erweiterten Namens des Attributknotens folgt aus der Eigenschaft namespace URI. Der Zeichenkettenwert des Knotens folgt aus der Verkettung aller Eigenschaften character code jedes Bestandteils der Eigenschaft children.\nDer Namensraum-URI des erweiterten Namens eines Attributknotens folgt aus der Eigenschaft namespace name. Der Zeichenkettenwert des Knotens folgt aus der Eigenschaft normalized value. Attributwerte werden gemäß der aktuellen Version der XML-Informationsmenge nicht weiter in einzelne Zeichen-Informationseinheiten zerlegt.\nEin Textknoten folgt aus einer Folge einer oder mehrerer aufeinander folgender Zeichen-Informationseinheiten. Der Zeichenkettenwert des Knotens folgt aus der Verkettung der Eigenschaften character code aller Zeichen-Informationseinheiten.\nEin Processing-Instruction-Knoten folgt aus einer Processing-Instruction-Informationseinheit. Der lokale Teil des erweiterten Namens des Knotens folgt aus der Eigenschaft target. (Der Teil Namensraum-URI des erweiterten Namens des Knotens ist leer.) Der Zeichenkettenwert des Knotens folgt aus der Eigenschaft content. Es gibt keine Processing-Instruction-Knoten für Processing-Instruction-Informationseinheiten, die Kinder der Dokumenttyp-Deklarations-Informationseinheit sind.\nEin Kommentarknoten folgt aus einer Kommentar-Informationseinheit. Der Zeichenkettenwert des Knotens folgt aus der Eigenschaft content. Es gibt keine Kommentarknoten für Kommentar-Informationseinheiten, die Kinder der Dokumenttyp-Deklarations-Informationseinheit sind.\nEin Namensraumknoten folgt aus einer Namensraumdeklarations-Informationseinheit. Der lokale Teil des erweiterten Namens des Knotens folgt aus der Eigenschaft prefix. (Der Teil Namensraum-URI des erweiterten Namens des Knotens ist leer.) Der Zeichenkettenwert des Knotens folgt aus der Eigenschaft namespace URI.\nEin Namensraumknoten folgt aus einer Namensraum-Informationseinheit. Der Zeichenkettenwert des Knotens folgt aus der Eigenschaft namespace name.\nWorld Wide Web Consortium: Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. Siehe http://www.edition-w3c.de/TR/2000/REC-xml-20001006.\nISO (International Organization for Standardization): ISO/IEC 10646-1:2000, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane, Edition: 2 (Monolingual). Internationaler Standard. Siehe http://www.iso.ch/cate/d29819.html.\nOasis (Organization for the Advancement of Structured Information Standards): Oasis XSLT/XPath Conformance Subcommittee. Siehe http://www.oasis-open.org/committees/xslt/.\nWorld Wide Web Consortium: XML Path Language (XPath) Version 1.0 Specification Errata. 29.09.2000. Siehe http://www.w3.org/1999/11/REC-xpath-19991116-errata.\nWorld Wide Web Consortium: XPath Requirements Version 2.0. W3C Working Draft. Siehe http://www.edition-w3c.de/TR/xpath20req.\nWorld Wide Web Consortium: XML Path Language (XPath) 2.0. W3C Working Draft. Siehe http://www.edition-w3c.de/TR/xpath20/.\nWorld Wide Web Consortium: XQuery 1.0 and XPath 2.0 Functions and Operators. W3C Working Draft. Siehe http://www.edition-w3c.de/TR/xquery-operators/.\nWorld Wide Web Consortium: XQuery: A Query Language for XML. W3C Working Draft. Siehe http://www.edition-w3c.de/TR/xquery.\nWorld Wide Web Consortium: XSL Transformations (XSLT) Version 2.0. W3C Working Draft. Siehe http://www.edition-w3c.de/TR/xslt20/.