Spezielle Knotentypen

(Auszug aus "XML in a Nutshell" von Elliotte Rusty Harold & W. Scott Means)

Obwohl der Zugriff auf die einzelnen Teile des XML-Dokuments schon durch das Node-Interface möglich wird, bietet der DOM-Kern trotzdem eine Reihe von spezielleren Interfaces, die einige typische Aufgaben des Programmierers vereinfachen. Dabei unterscheidet man grob zwischen zwei verschiedenen Typgruppen: den struktur- und den inhaltsorientierten Knoten.

Dokument im Speicher mit Verknüpfungen

Abbildung: Das Dokument im Speicher mit Verknüpfungen

Strukturorientierte Knotentypen

Innerhalb eines XML-Dokuments gibt es eine Reihe von syntaktischen Strukturen, die formal nicht als Inhalt angesehen werden. Die folgenden Interfaces erlauben die Darstellung derjenigen Teile des Dokuments, die keine Elementdaten enthalten.

DocumentType

Das Interface DocumentType bietet Zugriff auf die in der Dokumenttyp-Definition eingeführten Notationen, Entities, PUBLIC- und SYSTEM-Identifier sowie die lokalen Grammatikregeln. Da ein Dokument nur eine einzige !DOCTYPE-Deklaration enthalten darf, ist auch nur ein einziges Objekt vom Typ DocumentType pro DOM-Dokument erlaubt. Man erhält dieses Dokument über das Attribut doctype im Interface Document. Die Definition des Interfaces DocumentType wird in der folgenden Tabelle wiedergegeben.

Tabelle:Das von Node abgeleitete Interface DocumentType

Name Typ Nur-lesbar?
Attribute
entities NamedNodeMap
internalSubset DOMString
name DOMString
notations NamedNodeMap
publicId DOMString
systemId DOMString

Unter Verwendung der zusätzlichen Felder, die seit DOM Level 2 zur Verfügung stehen, ist es jetzt möglich, ein geparstes Dokument nur mit den vom DOM-Framework gelieferten Informationen vollständig zu rekonstruieren. Zurzeit gibt es keine Möglichkeit, mit Programmen den Inhalt von DocumentType-Knoten zu modifizieren.

ProcessingInstruction

Der Knotentyp ProcessingInstruction erlaubt den direkten Zugriff auf den Inhalt einer Verarbeitungsanweisung. Auch wenn Verarbeitungsanweisungen gewöhnlich direkt im Text des Dokuments stehen, können sie auch vor oder nach dem Wurzel-Element und in DTDs auftauchen. Die folgende Tabelle beschreibt die Attribute des Knotens ProcessingInstruction.

Tabelle: Das von Node abgeleixgtete Interface ProcessingInstruction

Name Typ Nur-lesbar?
Attribute
data DOMString
target DOMString

Denken Sie daran, dass nur für das Ziel (target) eine Syntax festgelegt ist, nämlich die eines XML-Tokens. Die restlichen Daten (data) dürfen dagegen bis zum abschließenden > eine beinahe beliebige Form haben. Weitere Informationen über die Anwendung (und den möglichen Missbrauch) von XML-Verarbeitungsanweisungen erhalten Sie unter Programmiermodelle.

Notation

XML-Notationen formalisieren die Deklaration eines Formats von externen, geparsten Entities und Verarbeitungsanweisungen. Die Liste der im Dokument enthaltenen Notationen ist als ein Objekt vom Typ NamedNodeMap in der DOCTYPE-Deklaration enthalten. Man erhält es über das Interface Document. Die Definition des Interfaces Notation wird in der folgenden Tabelle dargestellt.

Tabelle: Das von Node abgeleitete Interface Notation

Name Typ Nur-lesbar?
Attribute
publicId DOMString
systemId DOMString

Entity

Der Name des Interfaces Entity ist zunächst etwas zweideutig. Die Bedeutung wird aber klarer, wenn man weiß, dass es auch ein Interface EntityReference gibt, das ebenfalls im DOM-Kern enthalten ist. Das Interface Entity ermöglicht den Zugriff auf den Namen der Notation, den PUBLIC- und den SYSTEM-Identifier der Entity-Deklaration. Geparste Entity-Knoten haben childNodes, während ungeparste Entities einen notationName haben. Die Definition dieses Interfaces wird in der folgenden Tabelle dargestellt.

Tabelle: Das von Node abgeleitete Interface Entity

Name Typ Nur-lesbar? 2.0 3.0
Attribute
inputEncoding DOMString
notationName DOMString
publicId DOMString
systemId DOMString
xmlEncoding DOMString
xmlVersion DOMString

DOM Level 3 führt drei neue Attribute ein, die bei externen geparsten Entities angewandt werden: inputEncoding, xmlEncoding und xmlVersion. Diese zusätzlichen Informationen ermöglichen es, auf Basis des Werts des Attributs xmlVersion Wohlgeformtheitseinschränkungen für externe geparste Entities ordentlich zu erzwingen. Die beiden kodierungsbezogenen Attribute ermöglichen es, aus der DOM-Baumdarstellung die Dateien für externe geparste Entities präzise zu rekonstruieren.

Alle Attribute dieses Interfaces bieten nur lesenden Zugriff und können nicht während der Laufzeit geändert werden.

Inhaltsorientierte Knotentypen

Die in einem XML-Dokument tatsächlich enthaltenen Daten findet man innerhalb des Dokumentelements. Die folgenden Knotentypen bilden nicht-strukturelle Dokumentteile wie Zeichendaten, Elemente und Attributwerte ab.

Document

Hat der Parser ein XML-Dokument gelesen, besteht das Ergebnis aus einer einzelnen Instanz des Typs Document im Speicher. (Leere Document-Knotentypen können über das Interface DOMImplementation erzeugt werden.) Dieses Interface erlaubt den Zugriff auf die Dokumenttyp-Definition und auf den einzelnen, höchsten Knoten vom Typ Element, der die eigentlichen Daten des geparsten Dokuments (das documentElement) enthält. Darüber hinaus bietet das Interface auch Zugriff auf einige Methoden, mit denen ein Anwendungsprogramm neue Knoten erzeugen kann, die nicht schon beim Parsen des Dokuments generiert wurden. Die folgende Tabelle beschreibt alle Attribute und Methoden des Interfaces Document.

Tabelle: Das von Node abgeleitete Interface Document

Name Typ Nur-lesbar? 2.0 3.0
Attribute
doctype DocumentType
documentElement Element
documentURI DOMString
domConfig DOMConfiguration
implementation DOMImplementation
inputEncoding DOMString
strictErrorChecking boolean
xmlEncoding DOMString
xmlStandalone boolean
xmlVersion DOMString
Methoden
adoptNode Node
createAttribute Attr
createAttributeNS Attr
createCDATASection CDATASection
createComment Comment
createDocumentFragment DocumentFragment
createElement Element
createElementNS Element
createEntityReference EntityReference
createProcessingInstruction ProcessingInstruction
createTextNode Text
getElementById Element
getElementsByTagName NodeList
getElementsByTagNameNS NodeList
importNode Node
normalizeDocument void
renameNode Node

Die verschiedenen create...( )-Methoden sind für Anwendungen wichtig, in denen die Struktur eines Dokuments nach der Erzeugung durch den Parser erweitert oder verändert werden soll. Beachten Sie, dass man Knoten, die durch eine Instanz des Typs Document erzeugt wurden, nur in den Dokumentbaum des Document einsetzen kann, durch das sie erzeugt wurden. DOM Level 2 bot daher eine neue Methode importNode( ), die es ermöglicht, einen Knoten inhaltsgemäß von einem Document in ein anderes zu kopieren, eventuell mitsamt seiner Kinder. DOM Level 3 hat die Methode adoptNode() eingeführt, die einen vollständigen Konten-Unterbaum tatsächlich von einem Dokument in ein anderes verschiebt.

Abgesehen von den verschiedenen Methoden zur Erzeugung von Knoten gibt es auch Methoden zur Suche nach bestimmten XML-Elementen oder Listen von Elementen. Die Methoden getElementsByTagName( ) und getElementsByTagNameNS( ) generieren eine Liste aller XML-Elemente, die einen bestimmten Namen tragen. Letztere erlaubt die Einschränkung der Suche auf den vorgegebenen Namensraum. Die Methode getElementById( ) sucht nach demjenigen Element, das eine (XML-)Attribut-ID mit dem angegebenen Wert hat.

DOM Level 3 hat ebenfalls einige Attribute eingeführt, die hilfreich sind, wenn eine Anwendung ein XML-Dokument in der ursprünglichen Form rekonstruieren will, die es vor dem Parsen hatte. Die Attribute inputEncoding, xmlEncoding und xmlStandalone nehmen Informationen zu den Werten der XML-Deklaration des ursprünglichen Dokuments und zur Zeichenkodierung des Dokuments vor dem Parsen (und vor der Umwandlung in Unicode) auf.

Eine der wichtigeren Ergänzungen zu DOM in Level 3 war die Einführung der Unterstützung für die Dokumentvalidierung innerhalb des DOM-Baums selbst. Die Methode normalizeDocument( ) bietet dem Entwickler einen Mechanismus, um ausgehend vom DOM-Baum im Speicher das XML-Dokument im Grunde »neu zu parsen.« Das Attribut domConfig macht verschiedene Parameter verfügbar, über die gesteuert wird, wie die Normalisierung erfolgt. Durch Änderung des Attributs xmlVersion vor der Normalisierung ist es auch möglich, die Zielversion des XML zu ändern. Das veranlasst DOM, die Regeln für den Aufbau von XML-Namen zu erzwingen, die mit der ausgewählten XML-Version verbunden sind. Mehr Informationen zu den Unterschieden zwischen den XML-Versionen 1.0 und 1.1 finden Sie unter der XML-Referenz.

DocumentFragment

Anwendungsprogramme, die die Möglichkeit anbieten, ein vorhandenes Dokument zu bearbeiten, müssen manchmal Dokumentknoten außerhalb der Dokumenthierarchie des geparsten Dokuments ablegen. Ein Beispiel wäre etwa ein XML-Editor, der eine Zwischenablage anbietet. Wenn ein Teil des Dokuments ausgeschnitten wird, ist es möglich, die ausgeschnittenen Knoten, anstatt sie im Ausgangsdokument zu belassen, zeitweise in einen Knoten namens DocumentFragment zu verschieben, ohne sie zu löschen. Wenn sie dann wieder in das Dokument eingefügt werden sollen, können sie mit einer Methode wie Node.appendChild() wieder zurückgeschoben werden. Das von Node abgeleitete Interface DocumentFragment verfügt über keine spezifischen Attribute oder Methoden.

Element

Knoten des Typs Element sind die am häufigsten verwendeten Bestandteile eines typischen XML-Dokuments. Sie dienen unter anderem als Elternknoten für Instanzen der Interfaces Text, Comment, EntityReference, ProcessingInstruction, CDATASection und als Kindknoten vom Typ Element, die den eigentlichen Inhalt des XML-Dokuments bilden. Ferner erlauben sie den Zugang zu den Attr-Instanzen, die die XML-Attribute des jeweiligen Elements enthalten. Die folgende Tabelle enthält alle Attribute und Methoden, die vom Interface Element unterstützt werden.

Tabelle: Das von Node abgeleitete Interface Element

Name Typ Nur-lesend? 2.0 3.0
Attribute
schemaTypeInfo TypeInfo
tagName DOMString
Methoden
getAttribute DOMString
getAttributeNode Attr
getAttributeNodeNS Attr
getAttributeNS DOMString
getElementsByTagName NodeList
getElementsByTagNameNS NodeList
hasAttribute boolean
hasAttributeNS boolean
removeAttribute void
removeAttributeNode Attr
removeAttributeNS Attr
setAttribute void
setAttributeNode Attr
setAttributeNodeNS Attr
setAttributeNS Attr
setIdAttribute void
setIdAttributeNode void
setIdAttributeNS void

Attr

Da XML-Attribute entweder textuelle Werte oder Entity-Referenzen enthalten dürfen, werden in DOM die XML-Attribute als eine eigene Baumstruktur abgelegt. Das folgende XML-Fragment enthält ein Element mit zwei Attributen:

<!ENTITY bookcase_pic SYSTEM "bookcase.gif" NDATA gif>
<!ELEMENT picture EMPTY>
<!ATTLIST picture
   src ENTITY #REQUIRED
   alt CDATA #IMPLIED>
. . .
<picture src="bookcase_pic" alt="3/4 view of bookcase"/>

Das erste Attribut enthält eine Referenz auf ein ungeparstes Entity, das zweite beinhaltet nur eine einfache Zeichenkette. Da das DOM-Framework Attribute als Instanzen des Interfaces Attr ablegt, stellen einige Parser die Attributinhalte als Unterbäume/Äste von Node-Objekten dar. In diesem Beispiel würde das Attribut src eine Instanz des Objekts EntityReference enthalten. Beachten Sie, dass der nodeValue des Attr-Knotens die textuelle Repräsentation seiner Kinder, d.h. der Kinder des Attr-Knotens, enthält. Die folgende Tabelle enthält die Attribute und Methoden des Interfaces Attr.

Tabelle: Das von Node abgeleitete Interface Attr

Name Typ Nur-lesbar? 2.0 3.0
Attribute
specified boolean
isId boolean
name DOMString
value DOMString
ownerElement Element
schemaTypeInfo TypeInfo

Abgesehen vom Attributnamen und dem textuellen Wert, enthält das Interface Attr auch ein Flag namens specified, an dem man erkennen kann, ob der Wert explizit im XML-Dokument angegeben wurde oder implizit durch die !ATTLIST-Deklaration in der DTD. Ferner gibt es eine rückwärtsgerichtete Referenz auf den Knoten vom Typ Element, in dem die Attr-Instanz enthalten ist.

CharacterData

Einige Datentypen in einem DOM-Knotenbaum stellen Blöcke von Zeichendaten dar, die keine Markup-Zeichen enthalten. CharacterData ist ein abstraktes Interface, das gängige Methoden zur Manipulation von Texten unterstützt. Diese Methoden werden von den konkreten Interfaces Comment, Text und CDATASection verwendet. Die folgende Tabelle enthält die Attribute und Methoden, die vom Interface CharacterData unterstützt werden.

Tabelle: Das von Node abgeleitete Interface CharacterData

Name Typ Nur-lesbar? DOM 2.0
Attribute
data DOMString
length unsigned long
Methoden
appendData void
deleteData void
insertData void
replaceData void

Comment

DOM-Parser müssen die Inhalte von XML-Kommentaren nach dem Parsen nicht ausgeben. Daher ist es im besten Fall schlechte Programmierpraxis, wenn sich Ihre Anwendung auf Daten in Kommentaren verlässt. Falls Ihre Anwendung Zugriff auf Metadaten braucht, die nicht Bestandteil des zugrunde liegenden XML-Dokuments sein sollten, ziehen Sie stattdessen besser die Verwendung von Verarbeitungsanweisungen in Erwägung. Das Interface Comment, das von CharacterData abgeleitet ist, verfügt über keine interface-spezifischen Attribute oder Methoden, nur die, die es von Vorfahr-Interfaces erbt.

EntityReference

Enthält ein XML-Dokument Referenzen auf allgemeine Entities innerhalb seiner Elemente, kann ein DOM-kompatibler Parser diese Referenzen als EntityReference-Knoten zur Verfügung stellen. Dieses Verhalten ist allerdings nicht garantiert, weil der Parser die Entities oder Zeichenreferenzen nach Wahl auch durch die echte Unicode-Zeichenfolge ersetzen kann, die sie repräsentieren. Das Interface EntityReference, das von Node abgeleitet ist, verfügt über keine Interface-spezifischen Attribute oder Methoden.

Text

Die Zeichendaten aus einem XML-Dokument werden in Text-Knoten abgelegt. Text-Knoten sind entweder Kinder von Element- oder von Attr-Knoten. Unmittelbar im Anschluss an das Parsen wird jeder zusammenhängende Block von Zeichendaten aus dem XML-Ausgangsdokument direkt in einen einzelnen Text-Knoten überführt. Die Anwendung, die die geparsten Daten erhält, hat aber trotzdem nach Abschluss des Parsens die Möglichkeit, Text-Knoten einzufügen, zu löschen oder zu spalten. Auf diese Weise können Text-Knoten auch Seite für Seite im Dokumentbaum stehen. Die folgende Tabelle beschreibt das Text-Interface.

Tabelle: Das von CharacterData abgeleitete Interface Text

Name Typ Nur-lesbar? 2.0 3.0
Attribute
isElementContentWhitespace boolean
wholeText DOMString
Methoden
replaceWholeText Text
splitText Text

Die Methode splitText erlaubt es, einen vorhandenen Text-Knoten an einer angegebenen Stelle in zwei Knoten aufzuspalten. Eine solche Aufspaltung wäre zum Beispiel dann nützlich, wenn die den Baum bearbeitende Anwendung weitere Markup-Knoten in einen vorhandenen Bereich von Zeichendaten einfügen wollte. Nach der Aufspaltung ist es möglich, weitere Knoten in die resultierende Lücke einzufügen.

Eine weitere (in Level 3 eingeführte) Ergänzung ist das Attribut wholeText. Dieses Attribut liefert den gesamten Text, der sich im ausgewählten Text-Knoten und außerdem in allen benachbarten Text-Knoten befindet, in Dokumentreihenfolge zurück. Vor Level 3 musste man alle Kinder eines gegebenen Knotens aufzählen und von Hand aneinander hängen, um den vollständigen Text eines Knotens zu erhalten.

CDATASection

CDATA-Abschnitte sind eine bequeme Möglichkeit, um Zeichen, die normalerweise als Markup-Zeichen angesehen würden, in ein XML-Dokument einzubetten. In der Hierarchie des DOM-Dokuments werden diese Abschnitte als CDATASection-Knoten repräsentiert. Das Interface CDATASection, das von Text abgeleitet ist, verfügt über keine Interface-spezifischen Attribute oder Methoden.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

  


Copyright © 2005 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XML in a Nutshell" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de