Ausarbeitung

Seminar - XML und Datenbanken
DOM
Michael Stanek
54274
Sommersemester 2004
16. Juni 2004
Inhaltsverzeichnis
1 Einleitung
1.1 Was ist DOM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Die Geschichte von DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
4
2 Das DOM-Objektmodell
5
3 Module und Konzepte
3.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Vererbung oder Flache Sichtweise“ . . . . . . . . . . . . . . . . . . . . . . . .
”
3.3 Objektinstanzen & Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . .
7
7
8
8
4 Fundamentale Schnittstellen
4.1 Interface Node . . . . . . . . . .
4.2 Interface Document . . . . . . . .
4.3 Interface Element . . . . . . . . .
4.4 Interface Attr . . . . . . . . . . .
4.5 Interfaces CharacterData, Text &
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Comment
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
13
14
15
15
5 Zusammenfassung DOM vs. SAX
16
6 Index
17
7 Abbildungsverzeichnis
18
8 Literatur
19
2
1 Einleitung
1
3
Einleitung
Für die Verarbeitung und Weiterverwendung von XML-Dokumenten benötigt man Tools,
die das Auslesen der Informationen aus den Dokumenten ermöglichen. Das Erstellen von
XML-Dokumenten kann relativ einfach sein (z. B. eine Sequenz von Elementen bei geringem
Sprachumfang), der Zugriff auf die Informationen jedoch kann sich aufgrund der vielfältigen Sprachmöglichkeiten als sehr schwierig erweisen. So müssen beispielsweise Referenzen
auf Entities aufgelöst oder die Wohlgeformtheit und Gültigkeit von Dokumenten überprüft
werden. Diese Aufgaben übernehmen XML-Parser (XML-Prozessoren), die den Inhalt eines
XML-Dokumentes für die Applikation verfügbar machen.
Es gibt zwei standardisierte Schnittstellen für den Zugriff auf XML-Dokumente.
1. SAX – Simple API for XML
SAX realisiert ein ereignisgesteuertes Vorgehen zum Parsen von XML-Dokumenten.
Das XML-Dokument wird sequentiell abgearbeitet. Bereits während der Abarbeitung
wird die Applikation über das Auftreten von einzelner Bestandteile (z. B. Start- und
End-Tags von Elementen) durch den Aufruf spezieller Methoden informiert.
2. DOM – Document Object Model
DOM realisiert eine Schnittstelle zum Zugriff auf das gesamte Dokument. Der Zugriff erfolgt über Baumstrukturen. Außerdem wird die Navigation durch das XML-Dokument
unterstützt. Dadurch ist es der Applikation möglich, Informationen von Dokumentbestandteilen in beliebiger Reihenfolge auszulesen. Die Applikation kann darüber hinaus
das Dokument manipulieren oder umstrukturieren sowie neue Dokumente bzw. Dokumentanteile daraus generieren.
Im folgenden soll nun das Document Object Model genauer vorgestellt werden.
1.1
Was ist DOM?
Unter dem Document Object Model (DOM) verbirgt sich eine vom World Wide Web Consortium (W3C) definierte Programmierschnittstelle (API) zur allgemeinen Beschreibung von
Dokumenten. Es wurde im Hinblick auf WWW-Anwendungen ( Dynamic HTML“) entwickelt
”
und unterstützt deshalb gültige HTML- und wohlgeformte XML-Dokumente sowie eine Reihe weiterer gültiger Formate. Es ist eine abstrakte, sprachneutrale Schnittstellenbeschreibung
der Object Management Group (OMG) in der plattformunabhängigen Sprache IDL, daher
nur eine Vorlage, die je nach Programmierumgebung implementiert werden muss.
Das DOM definiert eine Menge von Schnittstellen und Methoden für das dynamische Erzeugen, Durchsuchen, Zugreifen, Ändern und Löschen von Dokumentinhalten und derer Struktur
(Navigation, Manipulation, Umstrukturierung). Dokumente werden unabhängig von der internen Datenstruktur nach außen hin objektorientiert repräsentiert. Alle Objekte des Dokuments
sind in eine hierarchische Baumstruktur eingegliedert.
1.2 Die Geschichte von DOM
1.2
4
Die Geschichte von DOM
Die Entwicklung von DOM begann schon 1996, als Netscape und Microsoft mit ihren unterschiedlichen Ansätzen zu DHTML begannen. Als im Sommer 1997 der Internet Explorer
4 und Netscape 4 erschienen, enthielten beide unterschiedliche Ansätze, ein HTML-Tag von
JavaScript aus anzusprechen, zu steuern und zu verändern. Codes mussten somit doppelt
geschrieben werden. Dieser unschöne Zustand führte zu dem Bestreben, eine Vereinheitlichung in der Programmierung zu erreichen, d.h. einen einheitlichen Code zu schaffen, wie
auf HTML-Tags, deren Inhalte und Attribute (oder Tags anderer Sprachen, z. B. XML, SVG
usw.) zugegriffen werden kann. Dabei sollte dieser Mechanismus standardisiert sein (ähnlich
wie HTML), damit sich jeder daran halten kann.
Am 1. Oktober 1998 wurde DOM Level 1 vom W3-Consortium standardisiert. DOM Level
1 enthielt zunächst nur die Objektstruktur und die Angaben, welche Objekte DOM definiert
(Node, Element, Document usw.). Auch viele Methoden waren enthalten, die später noch
näher vorgestellt werden (getElementById(), getElementsByTagName(),documentElement(),
usw.).
DOM Level 2, das am 13. November 2000 standardisiert wurde, vertieft die Definitionen
von Level 1. Die XML-Namensräume wurden unterstützt und gleichfalls spezifiziert, wie die
Cascading Style Sheets (CSS) von DOM aus verändert werden können. Neue Methoden traten
hinzu, die in DOM Level 1 noch nicht enthalten waren (z. B. hasAttributes(), import Node()).
Am 6. April 2004 wurde DOM Level 3 mit den Spezifikationen für DOM Level 3 Core und
DOM Level 3 Load and Save entgültig als Recommendiation“ (Empfehlungsstatus) verab”
schiedet, denn DOM Level 3 Validation war bereits am 27. Januar 2004 als Empfehlung
zugelassen worden.
DOM Level 3 Core erweitert das plattform- und sprachunabhängige Interface für den Zugang
und die dynamische Veränderung von Dokumentinhalten, -strukturen und -aussehen, welches
bereits in DOM Level 2 beschrieben worden ist. Desweiteren ist einen Standardsatz an Objekten für die Abbildung von XML-Daten und XML-Dokumenten (z. B. XML-Namespaces,
XML-Base, XML-Schema, usw.) enthalten.
Das Laden und Speichern von XML-Dokumenten und XML-Daten ist nun in einer plattformund sprachneutralen Art und Weise mit der DOM Level 3 Load und Save Recommendation
möglich. DOM Level 3 Load and Save ermöglicht das Hin-und Herwechseln zwischen einem
vollständigen XML-Dokument oder zwischen einem Fragment und einer DOM-Baumstruktur.
Einfache und fortschrittliche Filtermechanismen stehen für Webanwendungen zur Verfügung,
die es erlauben, statt des ganzen Dokuments lediglich ein Fragment zu laden und nur mit den
gewünschten Daten zu arbeiten.
Mit der erfolgreichen Fertigstellung der drei DOM Level 3 Spezifikationen (Core, Load and
Save und Validation) sind die Arbeiten an DOM abgeschlossen. Seit Beginn der Aktivität
im Jahr 1997 haben über 20 Organisationen und eingeladene Experten zu der Entwicklung
der 10 DOM-Standards beigetragen. Unter ihnen: AOL; Apple Computer; Arbortext; IBM;
Lucent; Macromedia; Merrill Lynch; Microsoft; NIST; Novell; Object Management Group;
Oracle; SoftQuad, Inc.; Software AG; Sun Microsystems; Web3D Consortium und X-Hive
Corporation.
2 Das DOM-Objektmodell
2
5
Das DOM-Objektmodell
Damit Applikationen mit Daten aus XML-Dokumenten arbeiten können, müssen die Daten
zugänglich und verwendbar“ gemacht werden. Die XML-Dokumente sind hierarchisch auf”
gebaut, d.h. sie besitzten eine logische Struktur, die mittels Parser überprüft wird. Wenn
das Dokument den Anforderungen genügt (Gültigkeit, Wohlgeformtheit), so wird das DOM”
Strukturmodell“ generiert. Auf diesem Strukturmodell“ setzen die Schnittstellen der Appli”
kationen auf, die schließlich mit den Daten arbeiten.
Abbildung 1: DOM-Strukturmodell
Da das DOM-Strukturmodell“ als logisches Modell auf günstige Art und Weise implemen”
tiert werden sollte, wurde ein Baum-ähnliches Modell gewählt. DOM schreibt weder das
Überführen von Dokumenten in einen Baum noch die Beziehungen zwischen den Objekten
vor. Der Begriff DOM-Baum“ entstand, da zum Erreichen der Daten Baum-Durchlauf”
”
Methoden“ verwendet werden.
Der DOM-Baum“ ist stark an die Struktur der XML-Dokumente angelehnt und ebenfalls
”
hierarchisch aufgebaut. Alle Elemente eines XML-Dokuments sind Knoten mit gewissen Eigenschaften, die zusätzlich mit in den Baum“ aufgenommen werden. Deshalb spricht man
”
nicht vom Datenmodell“ sondern bewusst vom Objektmodell“. Jeder Baum“ besitzt genau
”
”
”
ein Wurzelelement (Document), über das der Zugriff auf die restlichen Daten des Dokuments
erfolgt.
DOM bietet jedoch keine Binärrepräsentation der verarbeiteten Daten. Deshalb können die
Implementationen variieren. Jede Implementation muss Klassen erzeugen, die die sprachspezifischen Schnittstellen enthalten und der festgelegten Semantik entsprechen. Einzige Forderung
bei der Implementation ist der strukturelle Isomorphismus. Dies bedeutet, zwei unterschiedliche DOM-Implementationen müssen ein Dokument immer durch das gleiche Strukturmodell
darstellen.
2 Das DOM-Objektmodell
6
Beispiel für einen DOM-Baum generiert aus der Datei institut.xml:
institut.xml:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE institut SYSTEM "TEST.DTD">
<institut name="Institut für Informatik"
direktor="Prof. Dr. Hans-Dietrich Hecker">
<lehrstuhl name="Datenbanken und Informationssysteme">
<leiter name="Prof. Dr. Klaus Küspert"
email="[email protected]"/>
<mitarbeiter name="Dipl. Inf. Thomas Müller"
email="[email protected]"/>
<mitarbeiter name="Dipl. Inf. Knut Stolze"
email="[email protected]"/>
</lehrstuhl>
<lehrstuhl name="Softwaretechnik">
<leiter name="Prof. Dr. Wilhelm R. Rossak"
email="[email protected]"/>
<mitarbeiter name="Dr. rer. nat. Wolfram Amme"
email="[email protected]"/>
</lehrstuhl>
</institut>
institut.dtd:
<!ELEMENT institut (lehrstuhl+) >
<!ATTLIST institut name CDATA #REQUIRED>
<!ATTLIST institut direktor CDATA #REQUIRED>
<!ELEMENT lehrstuhl (leiter, mitarbeiter+)>
<!ATTLIST lehrstuhl name CDATA #REQUIRED>
<!ELEMENT leiter EMPTY>
<!ATTLIST leiter name CDATA #REQUIRED>
<!ATTLIST leiter email CDATA #REQUIRED>
<!ELEMENT mitarbeiter EMPTY>
<!ATTLIST mitarbeiter name CDATA #REQUIRED>
<!ATTLIST mitarbeiter email CDATA #REQUIRED>
DOM-Baum:
3 Module und Konzepte
3
7
Module und Konzepte
3.1
Module
Die DOM-Spezifikation gliedert sich in verschiedene Module. Eine DOM-Implementation muss
auf jeden Fall das Kern-Modul CORE-Modul implementieren. Zusätzlich stehen noch zahlreiche weitere Module zur Verfügung, die auf dem Kern-Modul aufsetzen.
Modul
Core
Views
Style Sheets
CSS
CSS2
Events
UIEvents
MouseEvents
MutationEvents
Traversal
Range
Funktionumfang
Definiert programmiersprachenunabhängige Schnittstellen
für den Zugriff und die Manipulation von Objekten eines
Dokuments. Alle weiteren Module können nur umgesetzt
werden, wenn auch Core implementiert ist.
Schnittstellen zur Realisierung verschiedener Sichten eines
Dokument.
Schnittstellen für den Zugriff auf Informationen eines Stylesheets.
Schnittstellen für den Zugriff auf Informationen einer CSSBeschreibung.
Schnittstellen für den Zugriff Informationen einer CSS2Beschreibung.
Schnittstellen zur plattform- und sprachunabhängigen Behandlung von Ereignissen.
Umfaßt eine Untermenge von Events, die den HTMLspezifischen Ereignissen aus DOM 0 entspricht.
Umfaßt eine Untermenge von Events, die den HTMLspezifischen Maus-Ereignissen aus DOM 0 entspricht.
Bietet Schnittstellen zur Benachrichtigung bei Ereignissen, durch welche Struktur oder Inhalt eines Dokuments
verändert werden (z. B. Hinzufügen oder Ändern eines Elements oder Attributs).
Bietet mit den Schnittstellen TreeWalker, NodeIterator
und NodeFilter Möglichkeiten zur einfachen Traversierung
von Dokumentbäumen an.
Schnittstellen für den Zugriff auf Bereiche eines XMLDokuments, wie sie beispielsweise durch Selektionen mit
der Maus am Bildschirm in der visuellen Darstellung gebildet werden können.
Abbildung 2: DOM-Module
3.2 Vererbung oder Flache Sichtweise“
”
3.2
8
Vererbung oder Flache Sichtweise“
”
Die Schnittstelle Node ist die Basisschnittstelle. Von ihr werden fast alle weiteren Schnittstellen der Knotentypen abgeleitet. Für den Zugriff auf einen speziellen Knotentypen werden
in der DOM Core Spezifikation zwei ziemlich unterschiedliche Varianten vorgestellt: Die eine
repräsentiert ein objekt-orientierten Ansatz mit hierarchischer Vererbung mit einer vereinfachten Sicht, die andere wickelt alles über ein einzige Schnittstelle, die Node-Schnittstelle,
ab.
• Objektorientierter Ansatz:
Die Schnittstelle Node im DOM Modul Core ist die Basis-Schnittstelle von der alle
weiteren Schnittstellen abgeleitet sind. Sie enthält alle wichtigen Eigenschaften und
Methoden, die an alle weiteren vererbt werden. Bei vielen Methodenaufrufen (z. B. appendChild() ) ist der Rückgabewert vom Typ Node und dieser muss dann erst in den
aktuellen Knotentyp umgewandelt werden (Type-Cast). Diese Type-Cast-Operationen
sind sehr teuer.
• Alles ist vom Typ Node“-Ansatz:
”
Dieser Ansatz besagt, dass alle Knoten vom Typ Node sind. Dies bedeutet, dass alle
Methodenaufrufe über die Node-Schnittstelle realisiert werden. Es sind also keine TypeCast’s für die Rückgabewerte erforderlich.
Wenn DOM in Performance-kritischen Umgebungen benutzt wird, erlaubt die Variante, bei
der ausschließlich die Node Schnittstelle benutzt wird, deutlich mehr Funktionalität. Weil viele
Benutzter den hierarchischen Ansatz leichter verstehen als den Älles ist vom Typ NodeÄnsatz,
werden beide Varianten vollständig unterstützt.
In der Praxis bedeutet dies, dass ein erheblicher Anteil an Redundanz in der Schnittstelle
steckt.
3.3
Objektinstanzen & Speicherverwaltung
Die durch DOM definierten APIs sind keine Klassen, sondern können eher als Interfaces
angesehen werden. Es werden nur Methoden mit definierten Operationen bereitgestellt und
keine expliziten Konstruktoren für Objekte (z. B. in Java X x=new X()), da DOM flach auf
Applikationen aufsetzt und daher ’kein Wissen’ über die Speicherverwaltung und die Datenstruktur der jeweiligen Implementation besitzt. Die Lösung dieses Problems liegt in DOM in
sogenannten Factory-Methoden. Je nach Implementation werden die Factory-Methoden auf
die entsprechenden internen Methoden und Aufrufe abgebildet, um Instanzen der Objekte zu
erstellen. Objekte, die das Interface X implementieren, werden durch die Factory-Methode
createX() im Document-Interface erschaffen. Diese Beziehung zum Document-Interface bewirkt, dass DOM-Objekte nur im Zusammenhang mit einem ganz bestimmten Dokument
exisitieren.
Eine Bedingung bei der Entwicklung der DOM-APIs war, dass sie für eine große Bandbreite
von Sprachen kompatibel sind. Darunter fallen sowohl Sprachen für den gewöhnlichen Nutzer als auch höhere Programmiersprachen. Deshalb müssen die DOM-APIs für eine Vielzahl
von Speicherverwaltungsmethoden funktionieren. Dies beginnt bei Sprachanbindungen, die
dem Nutzer keinerlei Speicherverwaltung bereitstellten, über Sprachanbindungen, die explizite Konstruktoren aber gleichzeitig automatische Garbage-Collecter verwenden, bis hin zu den
4 Fundamentale Schnittstellen
9
Sprachanbindungen, bei denen der Programmierer explizit Speicher für Objekte anfordert und
auch wieder freigibt. Um eine API für alle zu schaffen, wird in DOM auf Speicheradressierung
verzichtet. Stattdessen wird dies den Implementationen selbst überlassen.
Explizite Sprachanbindungen (Java und ECMAScript) sind durch DOM definiert und benötigen im Gegensatz zu anderen Sprachanbindungen (z. B. C oder C++) keine Methoden für
die Speicherverwaltung.
4
Fundamentale Schnittstellen
DOM bietet für jede Knotentypen eine eigene Schnittstelle mit unterschiedlichen Methoden
und Operationen an. Die Schnittstellen sind hierarchisch angelegt. Die folgende Abbildung
zeigt die Klassenhierarchie. Für jeden Knotentypen existieren spezialisierte Unterklassen, die
wiederum spezialisierte Methoden für den Zugriff auf Dokumentbestandteile sowie Dokumentinhalte besitzten.
Abbildung 3: DOM-Klassenhierarchie
4.1 Interface Node
4.1
10
Interface Node
Wie schon im Abschnitt 3.2 – Vererbung oder Flache Sichtweise“ – erwähnt, ist die Schnitt”
stelle Node die Basisschnittstelle für fast alle weiteren Dokumentbestandteile. Sie ist die
Primärklasse im DOM und vereinigt alle gemeinsamen Anteile der verschiedenen Knoten
eines XML-Baumes. Dazu gehören das Dokument selbst, Elemente, Attribute, Kommentare,
Textelemente und selbstdefinierte Typen. Alle Objekte, die das Node-Interface implementieren, müssen Methoden für den Umgang mit Kindknoten bereitstellen. Diese Methoden
ermöglichen eine Navigation innerhalb der Struktur des DOM-Baums, eine Manipulation der
Baumstruktur sowie das Auslesen der Knoteninformationen über Attribute.
Attribute zur
Identifikation
nodeName
nodeValue
nodeType
ownerDocument
Methoden zur StrukturNavigation
Manipulation
parentNode
appendChild
hasChildNodes insertBefore
firstChild
replaceChild
lastChild
removeChild
childNodes
cloneNode
previousSibling
nextSibling
Abbildung 4: Attribute und Methoden des Interface Node
Attriubte
Da fast alle Knotentypen vom Typ Node abstammen, muss jeder Knotentyp im DOM-Baum
eindeutig identifziert Knotenidentifikation werden können. Man kann über die Methode nodeType feststellen, um was für einen Knotentypen es sich handelt, um ggf. speziellere Methoden einsetzen zu können. Der Name und der Wert eines Knotens kann über nodeName und
nodeValue ausgelesen werden. Diese Methoden werden teilweise von spezielleren Methoden
überschrieben und liefern daher unter Umständen identische Ergebnisse.
Methoden
Bei den Methoden unterscheidet man zwischen zwei verschiedenen Gruppen. Dies sind zum
einen Methoden, die es ermöglichen, innerhalb der Struktur des DOM-Baums zu navigieren,
zum anderen Methoden, die Struktur des DOM-Baums verändern.
• Navigation im DOM-Baum
Die Schnittstelle Node besitzt Methoden, mit denen durch die Dokumentstruktur navigiert werden kann. Es kann sowohl ein Wechsel im hierarchischen Sinne (auf- oder
abwärts im Baum) als auch ein Wechsel auf gleicher Knotenebene erfolgen. Ob ein
Knoten überhaupt Kindknoten besitzt, kann durch die Methode hasChildNodes festgestellt werden. Besitzt ein Knoten nun Kindknoten, können alle Kindknoten mittels
childNodes erfragt werden. In diesem Fall erhält man dann eine Liste aller Kindknoten. Außerdem kann jeweils auf den ersten oder letzten Knoten der Knotenliste zugegriffen (firstChild, lastChild ) oder auch der Elternknoten mittels parentNode erfragt
4.1 Interface Node
11
werden. Einen Wechsel auf hierarchisch gleicher Knotenebene bewirken die Methoden
previousSibling, nextSibling, die jeweils den Zugriff auf den Vorgänger bzw. Nachfolger
ermöglichen.
Die folgende Abbildung zeigt ausgehend vom schwarzen Knoten die Ergebnisse der
einzelnen Methodenaufrufe.
1
2
3
4
5
6
=
=
=
=
=
=
parentNode()
previousSibling()
nextSibling()
childNodes()
firstChild()
lastChild()
Abbildung 5: Strukturnavigationsmethoden
• Manipulation der Dokumentstruktur
Man kann die Struktur eines eingelesenen XML-Dokumentes nicht nur erfragen bzw. in
ihr navigieren, sondern sie auch dynamisch verändern – manipulieren. Knoten können
neu eingefügt, ersetzt oder auch gelöscht werden.
Für das Einfügen eines neuen Knotens stehen sowohl die Methoden appendChild als auch
insertBefore zur Verfügung. Bei appendChild wird ein neuer Kindknoten an das Ende der
Liste aller Kindknoten gesetzt. Die Methode insertBefore fügt einen neuen Kindknoten
in der Knotenliste vor einem referenzierten Kindknoten ein. Sollte die Referenz sich als
null erweisen, so wird der Knoten ans Ende der Liste gehangen.
Zum Löschen eines Knotens wird die Methode removeChild genutzt. Der Knoten wird
aus der Liste gelöscht und liegt anschließend als Rückgabewert vor.
Obwohl mit den bereits vorgestellten Methoden ein Ersetzten von Knoten möglich ist
(insertBefore → removeChild), stellt die Schnittstelle Node dafür eine explizite Methode
replaceChild zur Verfügung. Diese Methode ersetzt einen alten Kindknoten durch einen
Neuen und liefert den Alten als Rückgabewert.
Bei allen drei Methoden, appendChild, insertBefore und replaceChild, gilt: Ist der neue
Kindknoten bereits im Baum enthalten, so wird dieser zuerst gelöscht und anschließend
neu eingefügt.
4.1 Interface Node
12
Die folgenden Abbildungen zeigen ausgehend vom schwarzen Knoten die Ergebnisse der
einzelnen Methodenaufrufe.
appendChild():
insertBefore():
replaceChild():
removeChild():
Abbildung 6: Strukturmanipulationsmethoden
4.2 Interface Document
4.2
13
Interface Document
Das Interface Document repräsentiert den Zugang zu einem XML-Dokument. Konzeptuell
gesehen, ist es die Wurzel bzw. der Einstieg eines jeden DOM-Baums und enthält somit
den primären Zugriff auf die Dokumentdaten. Da Elemente, Textknoten, Kommentare, etc.
nicht ohne den Zusammenhang zu einem Dokument existieren können, enthält das Interface
Document außerdem die Factory-Methoden (siehe Abschnitt Objektinstanzen & Speicherverwaltung), um diese Objekte zu erzeugen.
Auf einige der wichtigsten Methoden und Attribute dieser Schnittstelle soll im folgenden kurz
eingegangen werden.
Attribute
doctype
implementation
documentElement
Methoden
createDocumentFragment
createAttribute
createElement
createTextNode
createComment
createCDATASection
...
getElementsByTagName
Abbildung 7: Attribute und Methoden des Interface Document
Attribute
Die im Interface Document deklarierten Attribute beinhalten Informationen über das jeweilige Dokument. Das Attribut doctype enthält die Information zur DOCTYPE-Deklaration des
XML-Dokuments mit DTD- oder XML-Schema-Angabe. Sollte keine DOCTYPE-Deklaration
vorliegen, so wird diesem Attribut der Wert null zugeordnet. Ähnlich sieht es bei dem Attribut implementation aus, welches die Angaben zur verwendeten DOM-API enthält. Auch auf
das eigentliche Wurzelelement des XML-Dokuments kann über die Schnittstelle Document
zugegriffen werden. Der Zugriff erfolgt über das Attribut documentElement, über dass dann
zu allen restlichen Elemente des XML-Dokuments navigiert werden kann.
Die Werte der einzelnen Attribute können mittels getX() (für X ist der jeweilige Attributname
einzusetzen) abgefragt werden.
Methoden
Das Interface Document enthält wie bereits erwähnt die Factory-Methoden um Instanzen
verschiedener Knotentypen zu erzeugen. Einige Beispiele wären createAttribute(), createElement(), createTextNode(), createComment() und createCDATASection(). Aufgrund der
Zugehörigkeit von Objekten zu einem ganz bestimmten Dokument, wurden die FactoryMethoden im Interface Document deklariert. Deshalb besitzen Objekte, die erzeugt wurden,
ein Attribut ownerDocument, welches Sie an das Dokument bindet, in dessen Kontext sie
erschaffen wurden. Zusätzlich ist es möglich Teildokumente“ eines gesamten Dokuments zu
”
laden bzw. separat zu behandeln. Diese Dokumentenfragmente können mittels Methode createDocumentFragment() erschaffen werden.
4.3 Interface Element
14
Weiterhin wird vom Interface die Methode getElementByTagName() bereitgestellt. Diese Methode liefert eine geordnete Liste aller im Dokument enthaltenden Element-Knoten mit entsprechendem Namen.
4.3
Interface Element
Die Tags (Elemente) eines XML-Dokuments werden durch das Interface Element beschrieben.
Es sind der am häufigsten auftretende Knotentyp, da für jeden Tag des XML-Dokuments
einen Elementknoten im DOM-Baum existiert. XML-Elemente besitzen in den meisten Fällen
Attribute, die als Kindknoten der Elementknote im DOM-Baum auftreten. Da beim Arbeiten
im DOM-Baum somit häufig auf Elemente und deren Attribute zugegriffen wird, ist der Zugriff
auf die Attribute auch schon auf Knotenebene möglich.
Attribute
tagName
Methoden
hasAttribute
getAttribute
setAttribute
removeAttribute
getAttributeNode
setAttributeNode
removeAttributeNode
getElementsByTagName
Abbildung 8: Attribute und Methoden des Interface Element
Attribute
Im Interface Element wird lediglich ein Attribut deklariert. Hierbei handelt sich um das Attribut tagName, auf das nur lesend zugegriffen werden kann und den Elementnamen beinhaltet.
Methoden
Wie bereits kurz erläutert enthalten die meisten Elemente Attribute. Deshalb stellt das Interface Element Methoden zur Verfügung, um die Werte der Attribute oder Attribute selbst
zu generieren, zu ändern oder zu löschen.
Die Methode hasAttribute liefert einen Boolean-Wert zurück, der die Information enthält, ob
das Elemente ggf. Attributknoten besitzt. Methoden für den Zugriff auf die Attributwerte
sind getAttribute, setAttribute und removeAttribute. Für den Zugriff auf einen kompletten
Attributknoten werden die Methoden getAttributeNode, setAttributeNode und removeAttributeNode bereitgestellt.
Zusätzlich zum Zugriff auf die Attribute wird die Methode getElementsByTagName (wie im
Interface Document) angeboten, die eine geordnete Liste aller Unterelemente mit entsprechendem Namen zurückliefert (!!! nur Element-Knoten).
4.4 Interface Attr
4.4
15
Interface Attr
Obwohl das Interface Attr vom Interface Node abgeleitet ist, wird es nicht als echter Kind”
knoten“ angesehen, sondern als Eigenschaft von Elementknoten. Auch ist zu beachten das im
DOM-Core-Modul nicht zwischen den verschiedenen Datentypen von Attributen unterschieden wird, obwohl sie z. B. in der DTD explizit definiert wurden.
Attribute
getName
Methoden
getValue
setValue
getSpecified
Abbildung 9: Attribute und Methoden des Interface Attr
Methoden
Attribute gehören zu Elemente und werden mit Werten belegt. Neben den Methoden und
Attributen die vom geerbt wurden enthält das Interface Attr Methoden, um den eigenen
Wert zurückzugeben – getValue – bzw. zu ändern – setValue. Zusätzlich ist die Methode
getSpecified enthalten, die den Wert true zurückliefert, sofern der Wert des Attributs explizit
im XML-Dokument gesetzt wurde. Sollte es sich um einen DEFAULT-Wert handeln, so wird
false zurückgeliefert.
4.5
Interfaces CharacterData, Text & Comment
DOM definiert das Interface CharacterData als eine Oberklasse für alle Objekte, die Zeichenketten repräsentieren.
Folgende Methoden stehen zur Verfügung: appendData hängt am Ende des Strings einen
weiteren String an, insertData fügt an einer bestimmten Position einen String ein, replaceData
setzt einen String für eine bestimmte Anzahl von Zeichen neu ein und removeData entfernt
den String.
Das Interface Text repräsentiert den Inhalt von Elementen oder Attributen. Der Textinhalt
eines Elements wird als echter Kindknoten des Elements betrachtet. Dadurch kann auch ein
gemischter Inhalt, der zum Beispiel zwei Textpassagen getrennt durch ein Kommentar enthält,
ohne weiteres modelliert werden. Bezüglich dieses Textinhalts von Elementen gilt es allerdings
zu beachten, dass alle Geschwister vom Typ Text, die nicht durch andere Knoten getrennt
sind, bei der Serialisierung zu einem einzigen Textknoten zusammengefasst werden.
Neben den Methoden die vom Interface CharacterData geerbt werden, besitzt das Interface
Text zusätzlich die Methoden splitText , um einen Textknoten in zwei separate Textknoten
aufzuteilen sowie die Methode replaceWholeText, die den gesamten Inhalt des Textknotens
ersetzt.
Das Interface Comment repräsentiert Kommtare, die im XML-Dokument abgegeben wurden und ist ebenfalls vom Interface CharacterData abgeleitet. Es besitzt keine zusätzlichen
Methoden.
5 Zusammenfassung DOM vs. SAX
5
16
Zusammenfassung DOM vs. SAX
Der SAX-Parser ist schnell und praktisch, hat aber einen deutlichen Nachteil: Der Parser
geht nur sequentiell Zeichen für Zeichen durch. Der Vorteil von DOM gegenüber SAX: Die
eingelesene und geparste XML-Datei wird intern in einem Dokumentenbaum gespeichert bzw.
abgebildet. Über bestimmte Methoden sind die XML-Tags und deren Inhalte zugänglich.
Dadurch können die Inhalte bestimmter Tags ausgelesen oder verändert werden und natürlich
auch wieder als neue XML-Datei gespeichert werden.
Dieser Vorteil von DOM gegenüber SAX geht aber auch wieder mit einem Nachteil einher: Das
Parsen dauert länger, insbesondere bei größeren XML-Dateien. Gleichzeitig wächst mit DOM
der Speicher- und Ressourcen-Bedarf, da die XML-Datei und deren Inhalte im Hauptspeicher
gehalten werden müssen.
In Praxis werden häufig Mischformen eingesetzt. Für das Validieren von Dokumenten wird
SAX genutzt und anschließend wird mit DOM weitergearbeitet. Dabei wird überwiegend mit
Dokumentfragmenten gearbeitet, um den Bedarf an Speicherplatz einzugrenzen.
Index
setAttribute, 14
setAttributeNode, 14
Element-Schnittstelle, 14
Attr-Attribute, 15
getName, 15
Attr-Methoden, 15
getSpecified, 15
getValue, 15
setValue, 15
Attr-Schnittstelle, 15
Factory-Methoden, 8, 13
Knotenidentifikation, 10
Node-Attribute, 10
nodeName, 10
nodeType, 10
nodeValue, 10
ownerDocument, 13
Node-Methoden, 10
Manipulation, 11
appendChild, 11
insertBefore, 11
removeChild, 11
replaceChild, 11
Navigation, 10
childNodes, 10
firstChild, 10
hasChildNodes, 10
lastChild, 10
nextSibling, 11
parentNode, 10
previousSibling, 11
Node-Schnittstelle, 8, 10
CharacterData, 15
appendData, 15
insertData, 15
removeData, 15
replaceData, 15
Comment-Schnittstelle, 15
CORE-Modul, 7
createX(), 8
Document-Attribute, 13
doctype, 13
documentElement, 13
implementation, 13
Document-Methoden, 13
createAttribute(), 13
createCDATASection(), 13
createComment(), 13
createDocumentFragment, 13
createElement(), 13
createTextNode(), 13
Document-Schnittstelle, 13
documentFragment, 13
DOM Level 1, 4
DOM Level 2, 4
DOM Level 3, 4
DOM-Baum, 5
DOM-Strukturmodell, 5
Sprachanbindungen, 8
Strukturisomorphismus, 5
Text-Methoden, 15
replaceWholeText, 15
splitText, 15
Text-Schnittstelle, 15
Element-Attribute, 14
tagname, 14
Element-Methoden, 14
getAttribute, 14
getAttributeNode, 14
getElementsByTagName, 14
hasAttribute, 14
removeAttribute, 14
removeAttributeNode, 14
Vererbungsstrategien, 8
‘Alles ist vom Typ Node’-Ansatz, 8
Objektorientierter Ansatz, 8
World Wide Web Consortium (W3C), 3
17
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
DOM-Strukturmodell . . . . . . . . . . . . . . .
DOM-Module . . . . . . . . . . . . . . . . . . . .
DOM-Klassenhierarchie . . . . . . . . . . . . . .
Attribute und Methoden des Interface Node . . .
Strukturnavigationsmethoden . . . . . . . . . . .
Strukturmanipulationsmethoden . . . . . . . . .
Attribute und Methoden des Interface Document
Attribute und Methoden des Interface Element .
Attribute und Methoden des Interface Attr . . .
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
7
9
10
11
12
13
14
15
Literatur
[1]
World Wide Web Consortium. Document Object Model (DOM) Level 3 Core Specification, Version 1.0, Februar 2004. W3C Proposed Recommendation.
http://www.w3.org/TR/DOM-Level-3-Core
[2]
Philipp von Bassewitz, Martin Obermeier. Document Object Model, 30.11.2000.
http://wwweickel.in.tum.de/lehre/Seminare/Hauptseminar/WS00/DOM
/Presentation/paper.html#toc-0
[3]
Björn Hachmann. DOM & JDOM; Vergleich der Programmierschnittstellen für die interne Repräsentation von XML-Dokumenten, 07.05.2001.
http://www.fh-wedel.de/ si/seminare/ss01/Ausarbeitung/4.domjdom/dom2.htm
[4]
Christof Helfrich. Document Object Model; Interoperabilität für dynamische Web-Seiten
& XML-Anwendungen, 1998/99.
http://www2.informatik.uni-wuerzburg.de/mitarbeiter/wolfram/lehre/9899ws semdok
/dom/ausarbeitung/?i2statuslang=de
[5]
Frederic Ganner. Erstellen von XML-Dateien mit dem DOM, 16.01.2002.
http://www.aspheute.com/kategorien/XML.htm
[6]
Mario Jeckle. Extensible Markup Language (XML); Skript zur Vorlesung, 11.06.2004.
http://www.jeckle.de/vorlesung/xml/script.html#DOM
[7]
Alexander Hartelt. APIs für XML-Parser.
http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/edudoc/WebTut
/7 APIs fuer XMLParser/willkommen.html
[8]
Michael Seeboerger-Weichselbaum. Java/XML - Das bhv Taschenbuch, 19.07.2002.
http://www.xmlguru.de/html/ d/04buch/javaxml tb kap07-2.htm
[9]
uzi. Tutorial: XML-Parser. 06.01.2000.
http://www.uzi-web.de/parser/parser toc.htm
[10] Manuel Röllinghoff. XML-Parser, 24.11.2000.
http://www.fh-wedel.de/ si/seminare/ws00/Ausarbeitung/7.xmlparser/index.html
[11] Dr. Morad Ahmad. Einführung in XML; Skript zur Vorlesung, WS 03/04.
http://gretel.db.informatik.uni-kassel.de/Lehre/WS0304/XML/skript/k7.pdf
[12] Matthias Danner. Document Object Model (DOM), 24.11.2000.
http://www.informatik.fh-muenchen.de/ schieder/xml-00-01/06-dom/vortrag.pdf
19