DOM-Grundlagen

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

Das Kernstück von DOM ist ein Satz von abstrakten Interfaces. Verschiedene DOM-Implementierungen verwenden eigene Objekte, um die in der DOM-Spezifikation definierten Interfaces zu unterstützen. Die DOM-Interfaces selbst sind in Module untergliedert. Dadurch können Implementierungen auch nur Teile von DOM und nicht die komplette Spezifikation unterstützen. XML-Parser zum Beispiel brauchen keine Unterstützung für die HTML-spezifischen Teile des DOM anzubieten. Die Modularisierung hat einen einfachen Mechanismus hervorgebracht, der es Software-Entwicklern ermöglicht festzustellen, welche Teile des DOM von einer speziellen Implementierung unterstützt werden und welche nicht.

Aufeinander folgende Versionen des DOM werden als Level definiert. DOM Level 1 war das erste Release des W3C. Es konzentrierte sich auf die Verarbeitung von HTML und XML in einer Browser-Umgebung. Genauer gesagt, unterstützte es dynamisches HTML und bot eine Grundlage für die Verarbeitung von XML-Dokumenten. Level 1 beschrieb lediglich eine Objektstruktur und wie man diese manipulieren kann, weil es das Vorhandensein der Dokumente in der Browser-Umgebung voraussetzte. Dieses Level enthielt noch keine Angaben darüber, wie ein Dokument in diese Struktur geladen werden kann oder wie man ein Dokument ausgehend von seiner Struktur wiederherstellen kann.

In nachfolgenden Levels ist Funktionalität hinzugekommen. DOM Level 2, das als ein Satz von Spezifikationen mit jeweils einer Spezifikation pro Modul veröffentlicht wurde, umfasst Änderungen für den Kern und die HTML-Module des Levels 1 sowie neue Module für Views, Events, Style, Traversal und Range. DOM Level 3 hat abstrakte Schemas, das Laden, Speichern und XPath ergänzt und Änderungen für den Kern und die Event-Module enthalten.

Andere W3C-Spezifikationen haben DOM-Erweiterungen definiert, die ihren eigenen Bedürfnissen entsprechen. Mathematical Markup Language (MathML), Scalable Vector Graphics (SVG), Synchronized Multimedia Integration Language (SMIL) und SMIL Animation haben alle DOMs definiert, die jeweils Zugriff auf Details ihres eigenen Vokabulars ermöglichen.

Anmerkung: Einen vollständigen Überblick über die Anforderungen, denen diese Module genügen sollten, finden Sie unter Document Object Model (DOM) Requirements. Eine Auflistung sämtlicher DOM-Spezifikationen einschließlich der noch in der Entwicklung befindlichen finden Sie unter Document Object Model (DOM) Technical Reports. Das DOM ist per Referenz auch in eine Vielzahl anderer Spezifikationen eingebunden worden, vornehmlich in die Java-API für die XML-Verarbeitung (JAXP).

Die Entwickler, die das DOM für die XML-Verarbeitung einsetzen, nehmen typischerweise das Kernmodul als Grundlage für ihre Arbeit.

DOM-Notation

Eines der Ziele des Document Object Model ist die Neutralität in Bezug auf Betriebssystem und Programmiersprache. Aus diesem Grund sind alle Interfaces, die in ihrer Gesamtheit DOM bilden, in einer speziellen Notation verfasst. Diese Notation heißt Interface Description Language (IDL) und stammt von der Object Management Group. Wir werden sowohl in diesem Abschnitt als auch auf den Seiten der DOM-Referenz die Terminologie von IDL benutzen, um in der verwendeten Notation mit der DOM-Spezifikation übereinzustimmen. Wenn wir also im Folgenden zum Beispiel das Wort »Attribut« verwenden, ist dies im IDL-Jargon etwa gleichbedeutend mit der Instanz-Variablen bei C++ oder Java. Es ist nicht zu verwechseln mit dem »Attribut« in der XML-Terminologie: Hiermit ist ein Schlüssel-Wert-Paar im Start-Tag eines Elements gemeint.

Das sprachunabhängige IDL-Interface muss also in eine von der konkreten Programmiersprache abhängige Darstellung übersetzt werden. Die dabei verwendeten Regeln werden ebenfalls von der OMG vorgegeben. Betrachten wir als Beispiel das folgende Interface:

interface NodeList {
  Node               item(in unsigned long index);
  readonly attribute unsigned long    length;
};

In Java würde dieses Interface wie folgt aussehen:

package org.w3c.dom;

   public interface NodeList {
       public Node item(int index);

       public int getLength(  );

   }

In ECMAScript dagegen würden wir zum Beispiel Folgendes erhalten:

Object NodeList
   Das Objekt NodeList hat die folgenden Properties:
     length
       Dieser nur zum Lesen geeignete Wert ist vom Typ Zahl.
   Das Objekt NodeList hat die folgenden Methoden:
     item(index)
       Das Ergebnis dieser Methode ist ein Objekt vom Typ Node.
       Der Parameter index ist vom Typ Zahl.
       Anmerkung: Zur Dereferenzierung dieses Objekts kann man auch die Notation mit
       den eckigen Klammern verwenden, z.B. obj[1]). Dereferenzierung mit einer
       ganzen Zahl"index" ist identisch mit dem Aufruf der Methode item mit demselben
       "index".

Die Tabellen in diesem Abschnitt geben die Informationen wieder, die das DOM in IDL anbietet. Sie enthalten sowohl die verfügbaren Funktionalitäten als auch das Datum, ab dem sie jeweils verfügbar waren. Einzelne DOM-Implementierungen unterscheiden sich in ihrer Interpretation dieser Funktionalitäten. Lesen Sie daher unbedingt die Dokumentation der jeweils verwendeten Implementierung, um zu erfahren, wie sie die Standard-DOM-Interfaces in der jeweiligen Sprache abbildet.

Stärken und Schwächen von DOM

Wie alle anderen Programmierwerkzeuge ist auch DOM für bestimmte Problemstellungen besser geeignet als für andere. Da die Objekthierarchie von DOM die einzelnen Teile des Dokuments durch Referenzen verbindet, muss das Dokument zunächst vollständig gelesen werden und analysiert sein, bevor ein Anwendungsprogramm damit arbeiten kann. Dementsprechend wird das gesamte Dokument im RAM abgebildet, was unter Umständen mit einem signifikanten Performance-Einbruch verbunden sein kann, falls das RAM knapp wird. Die ersten DOM-Implementierungen haben typischerweise ein Vielfaches der Dateigröße gebraucht, um ein XML-Dokument im Speicher zu halten. Dieser Speicherverbrauch macht DOM ungeeignet für Anwendungen, die mit sehr umfangreichen Dokumenten umgehen müssen oder bei denen ein XML-Dokument besser nach und nach gelesen werden sollte, bevor es komplett geparst wird.

Trotzdem ist DOM für Anwendungen, die beliebigen Zugriff auf verschiedene Teile eines Dokuments zu unterschiedlichen Zeiten benötigen, oder für Anwendungen, die die Struktur eines XML-Dokuments zeitgleich ändern müssen, unter den vorhandenen Technologien eine der ausgereiftesten und am besten unterstützten.

  

<< 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