XML-Bäume

(Auszug aus "Perl & XML" von Erik T. Ray & Jason McIntosh)

Jedes XML-Dokument erlaubt eine Darstellung als eine Menge von Datenobjekten, die in einer nicht-zyklischen Struktur namens Baum miteinander verbunden sind. Jedes dieser Objekte, auch Node (Knoten) genannt, repräsentiert einen Teil des Dokuments, zum Beispiel ein Element, ein Stück Text oder eine Verarbeitungsanweisung. Der Knoten, der als root oder Wurzel bezeichnet wird, ist mit anderen Knoten verbunden, diese wiederum sind mit noch anderen Knoten verbunden und so weiter bis zu Knoten ohne weitere Verbindung. Zeichnet man dieses Bild auf, dann sieht das aus wie ein großer, buschiger Baum – daher der Name.

Eine Baumstruktur anstelle eines bestimmten XML-Ausschnitts ist sehr praktisch. Da der Baum keine Zyklen enthält (d. h. ein Knoten ist niemals direkt oder indirekt mit sich selbst verbunden), kann man einfache Strategien wie Schleifen und Rekursion kombinieren, ohne Endlosschleifen bedenken zu müssen. Wie im Baum eines Dateisystems kann man die Position eines jeden Knotens durch einen einfachen Ausdruck beschreiben. Wie bei wirklichen Bäumen kann man ein Stück herausbrechen und erhält einen kleineren Baum – ein Baum ist letzten Endes nur eine Menge von Unterbäumen seiner Wurzel, die mit dieser verbunden sind. Das beste ist aber, daß Ihnen alle Informationen an einer Stelle zur Verfügung stehen und Sie im Baum wie in einer Datenbank suchen können.

Für Programmierer ist ein Baum eine wesentliche Arbeitserleichterung. Bei der eventorientierten Verarbeitung ist es erforderlich, vorbeifließende Details festzuhalten, um sie in eine selbstaufgebaute Datenstruktur einzusetzen oder später bei der Ausgabe von Informationen zu verwenden. Das ist oft mühsam und kann bei komplexen Dokumenten extrem aufwändig sein. Falls man Informationen zusammenführen muß, die an verschiedenen Teilen des Dokuments stehen, kann einen das an die Grenzen des Wahnsinns treiben. Hat man dagegen einen Baum, der das Dokument enthält, dann stehen alle diese Details bequem zur Verfügung. Sie schreiben lediglich Code, der sich durch die Knoten bewegt und die für Sie relevanten Informationen herauszieht.

Nichts ist umsonst im Leben des Programmierers. Auch für den freien Zugriff auf beliebige Teile des Dokuments bezahlen wir. Der Aufbau eines Baums kostet Zeit und teure CPU-Zyklen. Das gilt erst recht, wenn Sie mit einem objektorientierten Baummodell arbeiten. Auch mit Hauptspeicher bezahlen wir, denn jeder Knoten dieses Baums beansprucht eine gewisse Menge RAM. Bei großen Dokumenten (Bäume mit Millionen von Knoten sind durchaus realistisch) würde man seine Maschine durch den Aufbau eines Baums in die Knie zwingen. Im Normalfall erzielt man mit der Verarbeitung von Bäumen aber recht gute Ergebnisse. Ganz besonders gilt das, wenn man zusätzlich mit etwas Optimierung arbeitet, wie wir das in diesem Kapitel noch tun werden. Es lohnt sich also nicht, das Thema schon abzuhaken.

Bei der Arbeit mit Bäumen werden gern Begriffe aus der Genealogie verwendet, um die Zusammenhänge zwischen den verschiedenen Knoten zu beschreiben. Ein Containerknoten heißt Vater (»Parent«, Elternknoten) derjenigen Knoten, die er enthält. Diese wiederum sind die Kinder des Containerknotens. Die Bedeutung der Begriffe Nachkomme, Vorfahr und Geschwister ergibt sich daraus dann von selbst. Zwei Geschwister haben denselben Vaterknoten und alle anderen Knoten sind Nachkommen ihres Vorfahren, des Wurzelknotens.

Je nach Implementierung gibt es verschiedene Arten von Bäumen. Ein Dokument erlaubt in einigen Dingen eine leicht unterschiedliche Modellierung. Zum Beispiel kann man darüber diskutieren, ob eine Entityreferenz und ein Stück Text die Objektklasse teilen oder nicht. Man muß also je nach Modul ein leicht unterschiedliches Schema berücksichtigen. In der folgenden Tabelle sehen wir eine gebräuchliche Auswahl von Knotentypen.

Tabelle: Typische Knotentypen

Typ	Properties
Element	Name, Attribute und Referenzen auf Kinder
Namensraum	Präfix und URI
Character data (Zeichendaten)	Textstring
Verarbeitungsanweisung (PI)	Target, Daten
Kommentar	Textstring
CDATA-Abschnitt	Textstring
Entityreferenz	Name und Ersetzungstext (oder System-ID und/oder Public-ID)

Einige Implementierungen definieren darüber hinaus auch Knotentypen für die DTD. Damit wird dem Programmierer ein bequemer Zugriff auf die Deklarationen der Elemente, Entities, Notationen und Attributlisten geboten. Auch für die XML-Deklaration und die Dokumenttypdeklaration findet man gelegentlich eigene Typen.

  

  

<< zurück

vor >>