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

F¨ ur die Verarbeitung und Weiterverwendung von XML-Dokumenten ben¨otigt man Tools, die das Auslesen der Informationen aus den Dokumenten erm¨oglichen. 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 vielf¨altigen Sprachm¨oglichkeiten als sehr schwierig erweisen. So m¨ ussen beispielsweise Referenzen auf Entities aufgel¨ost oder die Wohlgeformtheit und G¨ ultigkeit von Dokumenten u uft ¨berpr¨ werden. Diese Aufgaben u ¨bernehmen XML-Parser (XML-Prozessoren), die den Inhalt eines XML-Dokumentes f¨ ur die Applikation verf¨ ugbar machen. Es gibt zwei standardisierte Schnittstellen f¨ ur 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 w¨ahrend 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 unterst¨ utzt. Dadurch ist es der Applikation m¨oglich, Informationen von Dokumentbestandteilen in beliebiger Reihenfolge auszulesen. Die Applikation kann dar¨ uber 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 unterst¨ utzt deshalb g¨ ultige HTML- und wohlgeformte XML-Dokumente sowie eine Reihe weiterer g¨ ultiger Formate. Es ist eine abstrakte, sprachneutrale Schnittstellenbeschreibung der Object Management Group (OMG) in der plattformunabh¨angigen Sprache IDL, daher nur eine Vorlage, die je nach Programmierumgebung implementiert werden muss. Das DOM definiert eine Menge von Schnittstellen und Methoden f¨ ur das dynamische Erzeu¨ gen, Durchsuchen, Zugreifen, Andern und L¨oschen von Dokumentinhalten und derer Struktur (Navigation, Manipulation, Umstrukturierung). Dokumente werden unabh¨angig von der internen Datenstruktur nach außen hin objektorientiert repr¨asentiert. 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 Ans¨atzen zu DHTML begannen. Als im Sommer 1997 der Internet Explorer 4 und Netscape 4 erschienen, enthielten beide unterschiedliche Ans¨atze, ein HTML-Tag von JavaScript aus anzusprechen, zu steuern und zu ver¨andern. Codes mussten somit doppelt geschrieben werden. Dieser unsch¨one Zustand f¨ uhrte 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 (¨ahnlich wie HTML), damit sich jeder daran halten kann. Am 1. Oktober 1998 wurde DOM Level 1 vom W3-Consortium standardisiert. DOM Level 1 enthielt zun¨achst nur die Objektstruktur und die Angaben, welche Objekte DOM definiert (Node, Element, Document usw.). Auch viele Methoden waren enthalten, die sp¨ater noch n¨aher vorgestellt werden (getElementById(), getElementsByTagName(),documentElement(), usw.). DOM Level 2, das am 13. November 2000 standardisiert wurde, vertieft die Definitionen von Level 1. Die XML-Namensr¨aume wurden unterst¨ utzt und gleichfalls spezifiziert, wie die Cascading Style Sheets (CSS) von DOM aus ver¨andert werden k¨onnen. 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 f¨ ur DOM Level 3 Core und DOM Level 3 Load and Save entg¨ ultig 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 sprachunabh¨angige Interface f¨ ur den Zugang und die dynamische Ver¨anderung von Dokumentinhalten, -strukturen und -aussehen, welches bereits in DOM Level 2 beschrieben worden ist. Desweiteren ist einen Standardsatz an Objekten f¨ ur 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 m¨oglich. DOM Level 3 Load and Save erm¨oglicht das Hin-und Herwechseln zwischen einem vollst¨andigen XML-Dokument oder zwischen einem Fragment und einer DOM-Baumstruktur. Einfache und fortschrittliche Filtermechanismen stehen f¨ ur Webanwendungen zur Verf¨ ugung, die es erlauben, statt des ganzen Dokuments lediglich ein Fragment zu laden und nur mit den gew¨ unschten 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 Aktivit¨ at 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 k¨onnen, m¨ ussen die Daten zug¨anglich und verwendbar“ gemacht werden. Die XML-Dokumente sind hierarchisch auf” gebaut, d.h. sie besitzten eine logische Struktur, die mittels Parser u uft wird. Wenn ¨berpr¨ das Dokument den Anforderungen gen¨ ugt (G¨ ultigkeit, 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 g¨ unstige Art und Weise implemen” tiert werden sollte, wurde ein Baum-¨ahnliches Modell gew¨ahlt. DOM schreibt weder das ¨ Uberf¨ uhren 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 zus¨atzlich 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 Bin¨arrepr¨ asentation der verarbeiteten Daten. Deshalb k¨onnen 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 m¨ ussen ein Dokument immer durch das gleiche Strukturmodell darstellen.

2 Das DOM-Objektmodell

6

Beispiel f¨ ur einen DOM-Baum generiert aus der Datei institut.xml: institut.xml: institut.dtd:

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. Zus¨atzlich stehen noch zahlreiche weitere Module zur Verf¨ ugung, die auf dem Kern-Modul aufsetzen.

Modul Core

Views Style Sheets CSS CSS2 Events UIEvents MouseEvents MutationEvents

Traversal

Range

Funktionumfang Definiert programmiersprachenunabh¨angige Schnittstellen f¨ ur den Zugriff und die Manipulation von Objekten eines Dokuments. Alle weiteren Module k¨onnen nur umgesetzt werden, wenn auch Core implementiert ist. Schnittstellen zur Realisierung verschiedener Sichten eines Dokument. Schnittstellen f¨ ur den Zugriff auf Informationen eines Stylesheets. Schnittstellen f¨ ur den Zugriff auf Informationen einer CSSBeschreibung. Schnittstellen f¨ ur den Zugriff Informationen einer CSS2Beschreibung. Schnittstellen zur plattform- und sprachunabh¨angigen 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 ¨ ver¨andert werden (z. B. Hinzuf¨ ugen oder Andern eines Elements oder Attributs). Bietet mit den Schnittstellen TreeWalker, NodeIterator und NodeFilter M¨oglichkeiten zur einfachen Traversierung von Dokumentb¨aumen an. Schnittstellen f¨ ur den Zugriff auf Bereiche eines XMLDokuments, wie sie beispielsweise durch Selektionen mit der Maus am Bildschirm in der visuellen Darstellung gebildet werden k¨onnen. 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. F¨ ur den Zugriff auf einen speziellen Knotentypen werden in der DOM Core Spezifikation zwei ziemlich unterschiedliche Varianten vorgestellt: Die eine repr¨asentiert 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 enth¨alt alle wichtigen Eigenschaften und Methoden, die an alle weiteren vererbt werden. Bei vielen Methodenaufrufen (z. B. appendChild() ) ist der R¨ uckgabewert 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 f¨ ur die R¨ uckgabewerte erforderlich. Wenn DOM in Performance-kritischen Umgebungen benutzt wird, erlaubt die Variante, bei der ausschließlich die Node Schnittstelle benutzt wird, deutlich mehr Funktionalit¨at. Weil viele ¨ ¨ Benutzter den hierarchischen Ansatz leichter verstehen als den Alles ist vom Typ NodeAnsatz, werden beide Varianten vollst¨andig unterst¨ utzt. 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 k¨onnen eher als Interfaces angesehen werden. Es werden nur Methoden mit definierten Operationen bereitgestellt und keine expliziten Konstruktoren f¨ ur 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 L¨osung 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 f¨ ur eine große Bandbreite von Sprachen kompatibel sind. Darunter fallen sowohl Sprachen f¨ ur den gew¨ohnlichen Nutzer als auch h¨ohere Programmiersprachen. Deshalb m¨ ussen die DOM-APIs f¨ ur 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 f¨ ur Objekte anfordert und auch wieder freigibt. Um eine API f¨ ur 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 ben¨otigen im Gegensatz zu anderen Sprachanbindungen (z. B. C oder C++) keine Methoden f¨ ur die Speicherverwaltung.

4

Fundamentale Schnittstellen

DOM bietet f¨ ur jede Knotentypen eine eigene Schnittstelle mit unterschiedlichen Methoden und Operationen an. Die Schnittstellen sind hierarchisch angelegt. Die folgende Abbildung zeigt die Klassenhierarchie. F¨ ur jeden Knotentypen existieren spezialisierte Unterklassen, die wiederum spezialisierte Methoden f¨ ur 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“ – erw¨ahnt, ist die Schnitt” stelle Node die Basisschnittstelle f¨ ur fast alle weiteren Dokumentbestandteile. Sie ist die Prim¨arklasse im DOM und vereinigt alle gemeinsamen Anteile der verschiedenen Knoten eines XML-Baumes. Dazu geh¨oren das Dokument selbst, Elemente, Attribute, Kommentare, Textelemente und selbstdefinierte Typen. Alle Objekte, die das Node-Interface implementieren, m¨ ussen Methoden f¨ ur den Umgang mit Kindknoten bereitstellen. Diese Methoden erm¨oglichen 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 k¨onnen. Man kann u ¨ber die Methode nodeType feststellen, um was f¨ ur einen Knotentypen es sich handelt, um ggf. speziellere Methoden einsetzen zu k¨onnen. 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 Umst¨anden identische Ergebnisse. Methoden Bei den Methoden unterscheidet man zwischen zwei verschiedenen Gruppen. Dies sind zum einen Methoden, die es erm¨oglichen, innerhalb der Struktur des DOM-Baums zu navigieren, zum anderen Methoden, die Struktur des DOM-Baums ver¨andern. • 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 abw¨arts 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, k¨onnen alle Kindknoten mittels childNodes erfragt werden. In diesem Fall erh¨alt 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 Vorg¨anger bzw. Nachfolger erm¨ oglichen. 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 ver¨andern – manipulieren. Knoten k¨onnen neu eingef¨ ugt, ersetzt oder auch gel¨oscht werden. F¨ ur das Einf¨ ugen eines neuen Knotens stehen sowohl die Methoden appendChild als auch insertBefore zur Verf¨ ugung. Bei appendChild wird ein neuer Kindknoten an das Ende der Liste aller Kindknoten gesetzt. Die Methode insertBefore f¨ ugt 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 L¨oschen eines Knotens wird die Methode removeChild genutzt. Der Knoten wird aus der Liste gel¨oscht und liegt anschließend als R¨ uckgabewert vor. Obwohl mit den bereits vorgestellten Methoden ein Ersetzten von Knoten m¨oglich ist (insertBefore → removeChild), stellt die Schnittstelle Node daf¨ ur eine explizite Methode replaceChild zur Verf¨ ugung. Diese Methode ersetzt einen alten Kindknoten durch einen Neuen und liefert den Alten als R¨ uckgabewert. Bei allen drei Methoden, appendChild, insertBefore und replaceChild, gilt: Ist der neue Kindknoten bereits im Baum enthalten, so wird dieser zuerst gel¨oscht und anschließend neu eingef¨ ugt.

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 repr¨asentiert den Zugang zu einem XML-Dokument. Konzeptuell gesehen, ist es die Wurzel bzw. der Einstieg eines jeden DOM-Baums und enth¨alt somit den prim¨aren Zugriff auf die Dokumentdaten. Da Elemente, Textknoten, Kommentare, etc. nicht ohne den Zusammenhang zu einem Dokument existieren k¨onnen, enth¨alt 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 enth¨alt 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. Ahnlich sieht es bei dem Attribut implementation aus, welches die Angaben zur verwendeten DOM-API enth¨alt. 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 k¨onnen mittels getX() (f¨ ur X ist der jeweilige Attributname einzusetzen) abgefragt werden. Methoden Das Interface Document enth¨alt wie bereits erw¨ahnt die Factory-Methoden um Instanzen verschiedener Knotentypen zu erzeugen. Einige Beispiele w¨aren createAttribute(), createElement(), createTextNode(), createComment() und createCDATASection(). Aufgrund der Zugeh¨origkeit 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. Zus¨atzlich ist es m¨oglich Teildokumente“ eines gesamten Dokuments zu ” laden bzw. separat zu behandeln. Diese Dokumentenfragmente k¨onnen 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 h¨aufigsten auftretende Knotentyp, da f¨ ur jeden Tag des XML-Dokuments einen Elementknoten im DOM-Baum existiert. XML-Elemente besitzen in den meisten F¨allen Attribute, die als Kindknoten der Elementknote im DOM-Baum auftreten. Da beim Arbeiten im DOM-Baum somit h¨aufig auf Elemente und deren Attribute zugegriffen wird, ist der Zugriff auf die Attribute auch schon auf Knotenebene m¨oglich. 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 erl¨autert enthalten die meisten Elemente Attribute. Deshalb stellt das Interface Element Methoden zur Verf¨ ugung, um die Werte der Attribute oder Attribute selbst zu generieren, zu ¨andern oder zu l¨oschen. Die Methode hasAttribute liefert einen Boolean-Wert zur¨ uck, der die Information enth¨alt, ob das Elemente ggf. Attributknoten besitzt. Methoden f¨ ur den Zugriff auf die Attributwerte sind getAttribute, setAttribute und removeAttribute. F¨ ur den Zugriff auf einen kompletten Attributknoten werden die Methoden getAttributeNode, setAttributeNode und removeAttributeNode bereitgestellt. Zus¨atzlich zum Zugriff auf die Attribute wird die Methode getElementsByTagName (wie im Interface Document) angeboten, die eine geordnete Liste aller Unterelemente mit entsprechendem Namen zur¨ uckliefert (!!! 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 geh¨oren zu Elemente und werden mit Werten belegt. Neben den Methoden und Attributen die vom geerbt wurden enth¨alt das Interface Attr Methoden, um den eigenen Wert zur¨ uckzugeben – getValue – bzw. zu ¨andern – setValue. Zus¨atzlich ist die Methode getSpecified enthalten, die den Wert true zur¨ uckliefert, sofern der Wert des Attributs explizit im XML-Dokument gesetzt wurde. Sollte es sich um einen DEFAULT-Wert handeln, so wird false zur¨ uckgeliefert.

4.5

Interfaces CharacterData, Text & Comment

DOM definiert das Interface CharacterData als eine Oberklasse f¨ ur alle Objekte, die Zeichenketten repr¨asentieren. Folgende Methoden stehen zur Verf¨ ugung: appendData h¨angt am Ende des Strings einen weiteren String an, insertData f¨ ugt an einer bestimmten Position einen String ein, replaceData setzt einen String f¨ ur eine bestimmte Anzahl von Zeichen neu ein und removeData entfernt den String. Das Interface Text repr¨asentiert 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 enth¨alt, ohne weiteres modelliert werden. Bez¨ uglich 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 zus¨atzlich 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 repr¨asentiert Kommtare, die im XML-Dokument abgegeben wurden und ist ebenfalls vom Interface CharacterData abgeleitet. Es besitzt keine zus¨atzlichen 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 f¨ ur Zeichen durch. Der Vorteil von DOM gegen¨ uber SAX: Die eingelesene und geparste XML-Datei wird intern in einem Dokumentenbaum gespeichert bzw. ¨ abgebildet. Uber bestimmte Methoden sind die XML-Tags und deren Inhalte zug¨anglich. Dadurch k¨onnen die Inhalte bestimmter Tags ausgelesen oder ver¨andert werden und nat¨ urlich auch wieder als neue XML-Datei gespeichert werden. Dieser Vorteil von DOM gegen¨ uber SAX geht aber auch wieder mit einem Nachteil einher: Das Parsen dauert l¨anger, insbesondere bei gr¨oßeren XML-Dateien. Gleichzeitig w¨achst mit DOM der Speicher- und Ressourcen-Bedarf, da die XML-Datei und deren Inhalte im Hauptspeicher gehalten werden m¨ ussen. In Praxis werden h¨aufig Mischformen eingesetzt. F¨ ur 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]

Bj¨orn Hachmann. DOM & JDOM; Vergleich der Programmierschnittstellen f¨ ur die interne Repr¨asentation 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; Interoperabilit¨at f¨ ur 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 f¨ ur 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 R¨ollinghoff. XML-Parser, 24.11.2000. http://www.fh-wedel.de/ si/seminare/ws00/Ausarbeitung/7.xmlparser/index.html [11] Dr. Morad Ahmad. Einf¨ uhrung 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