Dieser letzte Satz bezieht sich auf Prädikate, die die Kontextposition und damit die Näheposition der gefilterten Knoten auswerten.

Zur Verdeutlichung der Vorgehensweise bei mehreren Prädikaten sei auf die beiden bereits diskutierten Beispiele

und

in Kapitel verwiesen.

Attribut- 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 ). 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.

Das 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.

Mö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 .

Wie 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.

Qualifizierte Namen werden also gemäß der Namensraum-Empfehlung 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: ]]>.

Gerade 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: ]]>. Richtig wäre stattdessen (der Vollständigkeit halber mit Namensraumdeklaration): ]]>. Entsprechend müssen in Lokalisierungpfaden alle Schritte vollständig qualifiziert sein: xhtml:div/xhtml:p.

Stellt 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 ]]> 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.

Schließ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: ]]>.

Handelt 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.

Beispielsweise wählt descendant::xhtml:* alle Nachkommen aus dem xhtml-Namensraum und attribute::xlink:* alle Attribute aus dem xlink-Namensraum aus.

Diese 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.

Offensichtlich 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.

Fü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').

Mö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::*.

Es 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 .

Diese 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.

Die 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 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.

Die Näheposition ist nur innerhalb von Prädikaten in Lokalisierungsschritten von Bedeutung, da hier die ausschlaggebende Achse bekannt ist. Die in 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.

Für vorwärtsgerichtete Achsen gilt daher folgende Gleichheit (am Beispiel following):

Dies ist bei rückwärtsgerichteten Achsen nicht der Fall. Stattdessen gilt hier (am Beispiel preceding):

Die 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" />.

Fü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.

Diese Definition soll anhand eines Beispiels veranschaulicht werden:

Achse 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.

Falls 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

liefert damit die gleiche Knotenmenge wie

Da die abgekürzte Syntax erst im folgenden Kapitel beschrieben wird, sollte als Beispiel hier besser child::para[3] verwendet werden.

Fü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.

Hier 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.

Davon kann man sich durch Bestimmung des vollständigen Ausdrucks leicht überzeugen:

Das Prädikat [1] wirkt damit auf die durch die child-Achse im zweiten Lokalisierungsschritt bestimmte Knotenmenge, wogegen es in /descendant::para[1] zur descendant-Achse gehört.

Die Kombination aus . und / ist unnötig und kann weggelassen werden. Ausdrücke der Form ./title oder ./@name können kürzer als title bzw. @name geschrieben werden.

Ein Blick in die unten stehende Grammatik zeigt, dass es sich bei . und .. um vollständige Lokalisierungsschritte handelt. Ihnen können also keine Prädikate folgen. Ausdrücke der Form .[self::par] oder ..[@name='foo'] sind nicht zulässig.

Der 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.

Der 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 verwendete Variablen haben immer einen definierten Wert. So wird durch das leere Element ]]> eine Variable namens foo:var definiert und mit der leeren Zeichenkette belegt.

Dieser 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.

Da 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 ) lässt sich so die Identität zweier Knoten feststellen.

Die 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 ), nicht deren Identität.

XPath definiert keine Operatoren für die Bestimmung von Durchschnitt und Differenz zweier Knotenmengen. Basierend auf dem Teilmengentest lassen sich diese Operationen allerdings berechnen:

Durchschnitt von $a und $b:

Differenz von $a und $b:

Damit lässt sich nun auch testen, ob der Kontextknoten ein Attributknoten ist (analog für Namensraumknoten):

Die bedingte Auswahl einer Knotenmenge aus zwei Alternativen abhängig von einem logischen Ausdruck kann durch folgende Konstruktion erreicht werden:

In den Programmiersprachen C, C++ und Java stellt der Fragezeichenoperator ?: diese Funktionalität bereit. Eine analoge Anwendung für Zeichenketten wird im Zusammenhang mit der Funktion substring in Kapitel vorgestellt.

In XSLT-Mustern, die eine Teilmenge der XPath-Ausdrücke bilden, wird der Operator | verwendet, um mögliche Alternativen anzugeben.

Auf 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.

Im obigen Beispiel preceding::foo[1] ist das Prädikat [1] Bestandteil des Lokalisierungsschrittes preceding::foo[1], während bei (preceding::foo)[1] das Prädikat [1] auf den Ausdruck (preceding::foo) angewendet wird (welcher in diesem Fall ein Lokalisierungsschritt ohne Prädikat ist).

Das 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][1], 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.

Bei der Betrachtung des Beispiels (preceding-sibling::* | following-sibling::*)[1] wird klar, dass für solche Ausdrücke eine von den beteiligten Achsen abhängende Knotenordnung nicht praktikabel ist.

An dieser Stelle sei darauf hingewiesen, dass über die in 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.

Angenommen, eine Variable namens divs enthält eine Knotenmenge von diversen div-Elementen (div1, div2, etc). Dann kann mittels $divs[1] 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.

Dabei 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[1]/following-sibling::* den nachfolgenden Geschwisterknoten des ersten Knotens aus $divs im XML-Dokument, und nicht den Nachfolger in $divs, also $divs[2]. 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.

Ausdrü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.

Wie 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.

Mit dieser Regelung lässt sich die Berechnung von Teilausdrücken und der Aufruf enthaltener Funktionen verhindern. Abgesehen von Performance-Aspekten hat sie im Zusammenhang mit XSLT allerdings nicht die gleiche Bedeutung wie in anderen Programmiersprachen.

So 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.

Da sich über Erweiterungsmechanismen jedoch Funktionen definieren lassen, die die genannten Eigenschaften nicht mehr besitzen, kann über eine Verknüpfung mit or oder and der Aufruf solcher Funktionen bei Bedarf verhindert werden.

Der Vergleich $x!="foo" ist genau dann wahr, wenn es wenigstens einen Knoten aus $x gibt, für den die Ungleichheit gilt, d.h. falsch, wenn es keinen solchen Knoten gibt. Damit ist not($x!="foo") wahr, wenn es keinen Knoten aus $x gibt, dessen Zeichenkettenwert verschieden von foo ist, d.h. wenn alle Knoten den Zeichenkettenwert foo besitzen.

Ein 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").

Bemerkenswert ist noch der Fall, dass die beteiligte Knotenmenge leer ist. Ein Vergleich @type!="warning" ist falsch, wenn kein Attribut type existiert. Dagegen liefert not(@type="warning") in diesem Fall den Wert wahr.

Es 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 .

Somit 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.

Unter Ausnutzung dieser Regeln kann z.B. die kleinste Zahl in einer Knotenmenge $set folgendermaßen bestimmt werden:

Ein 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:

Vorsicht 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.

XPath 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.

Die genannten speziellen Werte entstehen dann, wenn eine Rechenoperation einen Überlauf produzieren würde bzw. das Ergebnis nicht definiert ist. Beim Rechnen mit Zahlen in XPath können keine Fehler oder Ausnahmen auftreten.

An dieser Stelle sei bereits kurz auf die Produktion für Number in 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.

Es 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.

Gemäß Errata-Dokument ist die Semantik des einstelligen Operators - nicht spezifiziert. Stattdessen muss dieser letzte Absatz lauten:

Der zweistellige Operator - subtrahiert. Der einstellige Operator - berechnet die Negation. Beachten Sie, dass -0 negativ Null ergibt.

Gemäß Errata-Dokument ist die Semantik des Operators * nicht spezifiziert. An dieser Stelle muss folgender Absatz eingefügt werden:

Der 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.

Das 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 ).

Gemäß Errata-Dokument muss an dieser Stelle folgender Satz eingefügt werden:

Beachten Sie: Falls das Ergebnis nicht NaN ist, ist das Ergebnis genau dann positiv, wenn beide Operanden das gleiche Vorzeichen besitzen.

Der 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.

Der mod-Operator berechnet den genauen Rest, der sich bei der ganzzahligen Division zweier Gleitkommazahlen ergibt, ohne die Operanden zuvor auf ganze Zahlen zu runden.

Ein 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.

An dieser Stelle sei auf die Anmerkung zum Operator für die Subtraktion, das zweistellige Minus, in 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.

Ü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.

Im zweiten Aufzählungspunkt des Originaldokuments hat sich ein Fehler eingeschlichen. Da Funktionsnamen mit einem Präfix ausgestattet sein können, muss laut Errata-Dokument 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.

Das 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.

Die folgenden Beispiele zeigen, wie Bezeichner (und der *-Operator) abhängig vom Kontext unterschiedlich interpretiert werden müssen:

Für den letzten Knoten einer Knotenmenge gilt damit die Gleichheit position()=last(). Beachten Sie, dass die Nummerierung der Knoten bei 1 beginnt.

Wä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.

In 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:

Diese 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.

In Kapitel wird im Zusammenhang mit dem Mengenvereinigungsoperator | gezeigt, wie die Funktion count zur Bestimmung von Durchschnitt und Differenz zweier Mengen genutzt werden kann.

Diese 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.

Entsprechend der obigen Definition gilt also:

Die Knoten in der Ergebnisknotenmenge werden durch ein folgendes Prädikat in Dokumentordnung gefiltert und nicht in der Reihenfolge der angegebenen IDs.

Dagegen wird bei der Übergabe einer Knotenmenge, wie im Beispiel id(foo), von allen Knoten der Menge deren Zeichenkettenwert als Parameter verarbeitet und dieser wie ein IDREFS-Attribut interpretiert. Das Ergebnis ist die Vereinigung aller auf diese Weise bestimmten Knoten.

Die 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.

Es 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:

Fü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:

Fü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.

Für Processing Instructions liefert local-name das jeweilige Ziel, also beispielsweise für <?xml-stylesheet href='style.xsl'?> die Zeichenkette »xml-stylesheet«.

Für Textknoten, Kommentare und den Wurzelknoten liefert local-name die leere Zeichenkette.

Beispiele: 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.

Für einen folgendermaßen definierten Elementknoten

darf die Funktion name damit die Zeichenkette »y:foo« liefern, da durch das Präfix y der gleiche Namensraum repräsentiert wird wie durch x.

Die drei Funktionen local-name, namespace-uri und name werden in der folgenden Tabelle kurz zusammengefasst. Das Zeichen »-« steht dabei für die leere Zeichenkette:

Diese 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 erläutert.

Ü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:

Für XML-Dokumente, die keinen Gebrauch von Namensräumen machen, reicht bereits ein Vergleich mit der von der Funktion name gelieferten Zeichenkette.

Gemäß Errata-Dokument muss an dieser Stelle folgender Satz ergänzt werden:

Wenn das zweite Argument die leere Zeichenkette ist, wird der Wert wahr zurückgegeben.

Gemäß Errata-Dokument muss an dieser Stelle folgender Satz ergänzt werden:

Wenn das zweite Argument die leere Zeichenkette ist, wird der Wert wahr zurückgegeben.

Gemäß Errata-Dokument muss an dieser Stelle folgender Satz ergänzt werden:

Wenn das zweite Argument die leere Zeichenkette ist, wird die leere Zeichenkette zurückgegeben.

Gemäß Errata-Dokument muss an dieser Stelle folgender Satz ergänzt werden:

Wenn das zweite Argument die leere Zeichenkette ist, wird die im ersten Argument übergebene Zeichenkette zurückgegeben.

Die letzten vier Beispiele werden plausibel, wenn man die Definition für substring wortgetreu anwendet und beachtet, dass ein Vergleich mit dem Wert NaN immer falsch sowie jede Gleitkommazahl kleiner als positiv unendlich ist.

Mit 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 vorgestellt.

Unter 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

den Wert string, falls boolean-test wahr ist, und ansonsten die leere Zeichenkette. Die vollständige Formulierung eines bedingten Ausdrucks sieht damit folgendermaßen aus:

Solche 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.

Es 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:

Fü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:

Diese 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 .

Zur Erläuterung sei das folgende Beispiel angegeben. Häufig finden sich in XML-Dokumenten Textdaten, die folgendermaßen ausgezeichnet sind:

Der 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

liefert also nicht das erhoffte Ergebnis, sondern schlägt fehl. Korrekt ist in diesem Fall stattdessen ein Vergleich mit dem normalisierten Wert des Knotens:

Am 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:

Muss man aber normalisieren, erweist sich der folgende Test als ungeeignet:

Da 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:

Fü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.

In XSLT sähe das folgendermaßen aus:

Allerdings 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.

Allgemein 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

ausgedrü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 .

Mit 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:

Wä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.

Im Unterschied zu den Operatoren and und or, die in den Produktionen OrExpr bzw. AndExpr definiert werden, handelt es sich bei not um eine Funktion.

XPath definiert keine Literale für wahr und falsch. Soll ein boolescher Wert als Parameter an eine Funktion oder ein benanntes XSLT-Template übergeben werden, muss dafür eine der Funktionen true oder false benutzt werden.

Handelt es sich beim Kontextknoten dagegen um das para-Element im Beispiel

liefert lang("en") den Wert falsch. Der nächste Vorfahre mit einem xml:lang-Attribut ist in diesem Fall das Element sect, in welchem die Sprache auf de gesetzt wird.

Das 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.

Insbesondere 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', ',.', '.')).

Sie 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.

Die Funktion sum hilft noch in einem anderen Anwendungsfall: Aus der Definition des Verhaltens von number geht hervor, dass letztere eine leere Knotenmenge in den Wert NaN konvertiert. Ein Ausdruck foo - bar liefert damit NaN, falls wenigstens eines der Elemente foo oder bar nicht existiert. Möchte man stattdessen, dass in diesem Fall die Zahl 0 für nicht existierende Elemente angenommen wird, kann man dies über den Ausdruck sum(foo[1]) - sum(bar[1]) erreichen.

Gemäß Errata-Dokument muss an dieser Stelle folgender Absatz ergänzt werden:

Wenn 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.

Gemäß Errata-Dokument muss an dieser Stelle folgender Absatz ergänzt werden:

Wenn 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.

Davon kann man sich leicht selbst überzeugen:

Für -0 ergibt sich: floor(-0 + 0.5) = floor(0.5) = 0 (positiv Null)

Für -0.5 ergibt sich: floor(-0.5 + 0.5) = floor(0) = 0 (positiv Null)

Die 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.

Da außerhalb des Dokumentelements keine Textknoten auftreten dürfen, gilt also

oder 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.

Zum Vergleich: Im Document Object Model ist der Wert des vergleichbaren Attributs nodeValue für ein Document-Objekt dagegen die leere Zeichenkette.

Das 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«.

Damit gilt, dass der Zeichenkettenwert eines Elementknotens genauso als Verkettung der Zeichenkettenwerte seiner Element- und Textkinder in Dokumentordnung aufgefasst werden kann.

Zum Vergleich: Im Document Object Model ist dagegen der Wert des vergleichbaren Attributs nodeValue für ein Element-Objekt die leere Zeichenkette.

Wert 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 im Zusammenhang mit dem Operator | vorgestellten Technik bedienen.

Beispiel:

In 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.

Das 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.

Im 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.

Damit 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.

Entsprechend der XML-Namensraum-Empfehlung wirkt sich somit ein voreingestellter Namensraum im Gegensatz zu Elementknoten nicht auf Attribute ohne Präfix aus.

Normalisierung 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.

Attribute mit dem Namen »xmlns« oder dem Präfix »xmlns« werden nicht als Attributknoten, sondern als Namensraumknoten im Datenmodell repräsentiert.

Namensraumdeklarationen 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.

Wie bereits in Kapitel 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.

Da das XPath-Datenmodell keine Informationen darüber enthält, an welchen Stellen Namensraumdeklarationen im Dokument auftreten, besitzen die Beispiele

und

die gleiche Baumrepräsentation.

Nach einer Entscheidung des W3C-XML-Plenums ist die Behandlung relativer Namensraum-URIs implementationsabhängig. Gemäß Errata-Dokument muss dieser letzte Absatz durch den folgenden ersetzt werden:

Der 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.

Die 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.

Zur 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.

Namensraumknoten 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:

Da der Namensraumknoten für den voreingestellten Namensraum einen leeren Namen besitzt und daher nicht direkt als Knotentest angegeben werden kann, lässt sich ein solcher Knoten nur mit Hilfe eines geeigneten Prädikats auswählen:

Die folgende Processing Instruction

wird z.B. durch einen Knoten repräsentiert, dessen erweiterter Name [»xml-stylesheet«, »«] und dessen Zeichenkettenwert »href='style.xsl' title='Hauptstylesheet'« ist.

Die Abschnitte, die hier wie Attribute einer Processing Instruction aussehen (href und title), sind in Wirklichkeit nur Teile des Inhalts, also des Zeichenkettenwerts. Durch XPath werden an dieser Stelle keine Attributknoten bereitgestellt. Möchte man auf diese Pseudo-Attribute zugreifen, muss man sich mit den Funktionen für Zeichenketten behelfen.

Namensraumdeklarationen wirken sich nicht auf Processing Instructions aus.

Es ist nicht möglich, auf die Angaben innerhalb der XML-Deklaration zuzugreifen. Die Versionsnummer und die Kodierungsangabe gehören nicht zum XPath-Datenmodell.

Das 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 ein Comment-Objekt als Wert die Zeichenkette »#comment«.

Das 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:

Entsprechend 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 sieht hier stattdessen spezielle Objekte Text und CDATASection vor.

Einzelne Zeichendaten werden innerhalb des Datenmodells nicht separat repräsentiert. Zur Verarbeitung muss deshalb auf die bereitgestellten Zeichenkettenfunktionen zurückgegriffen werden.

Gemäß Errata-Dokument muss an dieser Stelle folgender Satz eingefügt werden:

Leerraum außerhalb des Dokumentelements erzeugt keine Textknoten.

Genau 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 beruht auf der Annahme, dass solche Leerraum-Textknoten vorhanden sind. Das ist auch das Standardverhalten in 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 ) auftreten, niemals entfernt.

Die 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()[1] für das folgende Beispiel hängt entscheidend davon ab, ob Leerraum-Textknoten mitgezählt werden oder nicht:

Das 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«.