Konzepte Content-Repräsentation & Markup-Sprachen

11.3 Das Datenmodell von XPath

Die Strukturkomponenten eines Dokuments werden in XPath als Knoten (nodes) dargestellt, die ähnliche Eigenschaften aufweisen wie der Basisknotentyp des Document Object Model (vgl. Lerneinheit 8). Das bedeutet, XPath-Knoten können in einer Baumstruktur angeordnet werden, die die logische Elementstruktur eines XML-Dokuments repräsentiert. Neben der hierarchischen Struktur besteht folglich auch eine Document Order genannte implizite Ordnung der Knoten innerhalb des Baums, die dem Auftreten der Strukturkomponenten in der linearisierten Dokumentdarstellung entspricht.

Trotz der Gemeinsamkeiten zum DOM ist zu beachten, daß XPath ausschließlich auf die Informationsextraktion abzielt. Daher sind keine Funktionen zur Manipulation der Knoten bzw. der Verknüpfungen zwischen Knoten vorgesehen.

Um verschiedene Arten von Strukturkomponenten in XPath-Ausdrücken unterscheiden zu können, besitzt jeder Knoten einen Typ, auf den sich bestimmte Funktionen anwenden lassen. Da keinerlei Informationen über das verwendete Markup benötigt werden, stehen hier allerdings nur sieben Typen zur Verfügung, während beim DOM zwölf Knotenarten unterschieden werden. Folgende Aufstellung gibt einen kurzen Überblick über die wesentlichen Eigenschaften der Knotentypen in XPath:

Wurzelknoten (root node)

Der Wurzelknoten befindet sich immer oberhalb aller anderen Knoten in der Baumstruktur. Für jedes XML-Dokument existiert genau ein solcher Knoten in der zugehörigen Baumdarstellung. Somit ist er selbst dann vorhanden, wenn das jeweilige Dokument leer ist. Ansonsten enthält er neben der Knotendarstellung des Dokumentelements entsprechende Einträge für Processing Instructions und Kommentare, die im Prolog oder nach dem Ende des Dokumentelements auftreten.

Elementknoten (element nodes)

Elemente eines XML-Dokuments werden als Elementknoten repräsentiert. Sie können als Kindknoten anderer Elementknoten oder (im Falle des Dokumentelements) des Wurzelknotens auftreten. Die Attribute eines Elements werden als Attributknoten dargestellt, der mit dem jeweiligen Elementknoten assoziiert ist.

Attributknoten (attribute nodes)

Jedes Attribut im Starttag eines Elements im XML-Dokument wird als Attributknoten unterhalb des entsprechenden Elementknotens repräsentiert. Stehen zudem Informationen über die Attributdeklaration zur Verfügung, so werden darüber hinaus alle Attribute eines Elements in die Baumdarstellung aufgenommen, die über einen Vorgabewert verfügen.

Textknoten (text nodes)

Die in Mixed-Content auftretenden Zeichen, die kein Markup darstellen, werden nach der Normalisierung durch den XML-Prozessor (vgl. Lerneinheit 7) als Textknoten repräsentiert. Berücksichtigt werden dabei allerdings ausschließlich die Textzeichen im Inhalt von Elementen — Attributwerte, Kommentare und Processing Instructions werden hingegen als eigenständige Knoten in den Baum aufgenommen.

Bei der Erzeugung der Baumdarstellung werden so wenig Textknoten wie möglich erzeugt. Alle direkt nebeneinanderliegenden Textzeichen in den Inhaltsdaten eines Elements werden folglich zu einer Zeichenkette zusammengefaßt, bevor sie in einen Knoten überführt werden.

Namespace-Knoten (namespace nodes)

Für jedes Element in einem XML-Dokument können neben dem Namespace, in dem es deklariert wurde, weitere Bindungen zwischen Namespace-Namen und -Präfixen gültig sein. Daher wird jedem Elementknoten in der Baumdarstellung eine Reihe von Namespace-Knoten zugeordnet, die diese Bindungen repräsentieren.

Processing-Instruction-Knoten (processing instruction nodes)

Für jede Processing Instruction (PI), die sich nicht innerhalb der DTD befindet, wird ein Processing-Instruction-Knoten in der Baumdarstellung erzeugt. Das Ziel (target) der PI dient als Name, unter dem dieser Knoten ansprechbar ist, während die nachfolgenden Inhaltsdaten als Zeichenkette im Inhalt des Processing-Instruction-Knotens gespeichert werden. Zu beachten ist, daß diese Zeichenkette für einen XML-Prozessor im allgemeinen Fall keinerlei Bedeutung hat (die einzige Ausnahme bildet das Ziel xml) und sie daher nur von der jeweiligen Ziel-Anwendung parsiert wird. Eine Unterteilung in Schlüssel/Wert-Paare oder ähnliche Formate wird demzufolge nicht vorgenommen.

Des weiteren ist darauf hinzuweisen, daß die XML-Deklaration eine Sonderrolle einnimmt: Sie wird in XPath nicht als Processing Instruction im eigentlichen Sinne aufgefaßt und erscheint daher nicht als Knoten in der Baumrepräsentation.

Kommentarknoten (comment nodes)

Kommentare, die sich nicht innerhalb der DTD befinden, werden bei der Baumerzeugung als Kommentarknoten dargestellt. Alle Zeichendaten aus dem Kommentar werden literal in den Knoteninhalt übernommen.

Anhand des in Beispiel 1 angegebenen Dokuments läßt sich die Rolle der unterschiedlichen Knotentypen im XPath-Datenmodell verdeutlichen.

Beispiel 1. Ein XHTML-Dokument

<?xml version="1.0" encoding="iso-8859-1" ?>
<!-- link with stylesheet: -->
<?xml-stylesheet href="teia.css" type="text/css" ?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ATTLIST body background CDATA "white">

<!--  
     declaration of meta element
     (cf. http://example.com/documents/profile)
-->
<!ELEMENT p:meta (#PCDATA)>
<!ATTLIST p:meta category CDATA #IMPLIED>

<!ATTLIST title  p:title CDATA  #IMPLIED>
<!ATTLIST title  p:xref  CDATA  #IMPLIED>
]>

<html xmlns="http://www.w3.org/1999/xhtml">
  <head xmlns:p="http://example.com/documents/profile">
    <title p:title="testdoc">Ein einfaches Testdokument</title>
    <p:meta category="creator">John Doe <![CDATA[<jdoe@example.com>]]></p:meta>
  </head>
  <body>
    <h1 id="intro">Einleitung</h1>
    <p xmlns="" class="copy-note">&copy; 2001<!-- August 17, 2001-->, 
       Teles European Internet Academy
    </p>
  </body>
</html>

<!-- 
Local variables:
mode: xml
End:
-->

Im angegebenen Beispieldokument sind alle wesentlichen Bestandteile eines typischen XML-Dokuments vertreten: Der Prolog enthält neben der Dokumenttyp-Deklaration einen Kommentar sowie eine Processing Instruction, die bestimmten Anwendungsprogrammen die Einbindung eines externen Stylesheet ermöglicht. Die formale Spezifikation der DTD für das Dokument erfolgt vorwiegend in einer externen Datei, ergänzt um einen internen Teil. Hier erfolgt insbesondere die Definition des Elementtyps meta, der dem Namespace http://example.com/documents/profile angehören soll. Auf eine Anpassung des Content Models für den Elementtyp head wurde hier verzichtet, um das Beispiel einfacher zu gestalten.

Nach dem Prolog folgen das Dokumentelement und ein abschließender Kommentar. Im Starttag des Dokumentelements wird der Default-Namespace http://www.w3.org/1999/xhtml festgelegt. Bis auf die Elemente meta und p befinden sich alle Elemente in diesem Default-Namensraum. Die Bindung des Namespace-Präfixes p erfolgt im Element head, so daß es für dieses und alle untergeordneten Elemente Gültigkeit besitzt, einschließlich des Vorkommens von p:meta. Da das Attribut category im Namensraum des zugehörigen Elements liegt, wird hier kein Namespace-Präfix benötigt. Die DTD sieht außerdem vor, daß das Element title zwei Attribute aus dem mit p verknüpften Namensraum besitzen kann. In der Dokumentinstanz wird von diesen jedoch nur p:title verwendet.

Zum Elementtyp body aus dem externen Teil der DTD wird ein Attribut background deklariert, das einen Vorgabewert erhält. Das einzige Vorkommen von body in der Dokumentinstanz umfaßt somit implizit eine entsprechende Definition, da keine abweichenden Angaben im Starttag des Elements gemacht wurden. Im Inhalt dieses Elements befinden sich zwei weitere Elemente, von denen eines dem XHTML-Namensraum angehört, während das andere den Default-Namespace löscht und somit samt Attributen dem unbenannten globalen Namensraum zugeordnet wird.

Die im Dokument vorkommenden Textdaten wurden mit einer Marked Section und einer Entity-Referenz angereichert, um weitere typische Eigenschaften von XML-Dokumenten aufzuzeigen. Der Text innerhalb des p-Elements ist zudem von einem Kommentar unterbrochen.

Eine mögliche Darstellung als Baumstruktur unter Verwendung des Datenmodells von XPath zeigt Abbildung 1:

Abbildung 1. Darstellung eines XML-Dokuments unter Verwendung des XPath-Datenmodells

In der Abbildung ist die grundsätzliche Baumstruktur zu erkennen, die starke Ähnlichkeit mit den bisher kennengelernten Darstellungen eines Dokuments als DOM oder auch als Grove besitzt (vgl. Lerneinheit 8). Zu beachten ist, daß hier im Gegensatz zu vielen Abbildungen in den vorhergehenden Lerneinheiten neben der Elementstruktur weitere Markup-Informationen visualisiert werden. Die Knotentypen des XPath-Datenmodells werden daher durch unterschiedliche geometrische Formen repräsentiert. Strukturkomponenten, die einem bestimmten Namensraum angehören, wurden zudem mit der gleichen Färbung versehen wie die jeweiligen Namespace-Knoten.

Ein flüchtiger Blick auf den Baum zeigt bereits, daß er über zahlreiche Textknoten verfügt, die in den bisherigen Darstellungen vernachlässigt wurden. Bei genauer Betrachtung wird deutlich, daß viele Elemente unterhalb des Dokumentelements von Textknoten umschlossen sind, die ausschließlich Whitespace characters (also Leerzeichen, horizontale Tabulatorzeichen und das Zeilenendezeichen) enthalten. Als Bestandteil des Information set werden diese Zeichen nämlich auch von einem validierenden XML-Prozessor zur Verfügung gestellt, selbst wenn sie im Elementkontext, d.h. Element Content, auftreten.

Darüber hinaus ist zu beachten, daß nicht alle in der DTD enthaltenen Informationen im XPath-Baum verfügbar sind. So wird dem Elementknoten für das body-Element zwar ein Knoten für das Attribut background und dem entsprechenden Vorgabewert aus der DTD hinzugefügt, doch kann anhand des XPath-Baums nicht nachvollzogen werden, daß das Attribut nicht im Starttag des Elements aufgeführt wurde. Das Attribut mit dem Bezeichner p:xref ist konsequenterweise überhaupt nicht in der Darstellung vertreten, da es als #IMPLIED deklariert wurde und somit über keinen Vorgabewert verfügt.

Bei Verwendung eines nicht-validierenden Parsers stehen zudem einige Informationen aus der DTD nicht für die weitere Verarbeitung zur Verfügung, obwohl sie im Datenmodell von XPath repräsentiert werden könnten. Inbesondere gilt dies für Attribute des Typs ID sowie für Vorgabewerte von Attributen. Robuste XPath-Anwendungen sollten folglich so gestaltet sein, daß keine DTD-Informationen in der Knotendarstellung vorausgesetzt werden, da ansonsten unterschiedliche Ergebnisse zwischen validierenden und nicht-validierenden Parsern zu erwarten sind.

Kommentare (0)

Ihr Kommentar

Name