Die DOM-Spezifikationen

(Auszug aus "Python & XML" von Christopher A. Jones & Fred L. Drake, Jr.)

DOM wird durch eine Reihe von W3C-Empfehlungen definiert. Die Spezifikationen behandeln ausführlich XML (sonst würden wir es nicht in diesem Buch beschreiben), aber auch andere Dinge. Die erste Version von DOM kam ursprünglich aus der HTML-Welt; Browser-Hersteller haben es in verschiedenen Abwandlungen als Teil der APIs für clientseitige Skripten in Webseiten erfunden. Da diese Hersteller alle unterschiedliche Schnittstellen implementierten, gab es einen Aufruf seitens der Erzeuger von Inhalten nach einer standardisierten Schnittstelle, damit ihre Seiten auf unterschiedlichen Browsern wenigstens auf ungefähr gleiche Art funktionieren würden. Da das W3C die beste verfügbare Grundlage ist, auf der diese Hersteller eine gemeinsame Spezifikation aufbauen konnten, werden die DOM-Spezifikationen dort entwickelt.

Alle Standardisierungsgremien haben mit der Langlebigkeit ihrer Spezifikationen zu kämpfen, und das W3C ist keine Ausnahme, auch wenn es ziemlich jung ist, verglichen mit traditionelleren Standardisierungsgruppen wie ANSI und ISO. Wegen seines geringen Alters mußte sich das W3C fast seit Anbeginn mit diesen Problemen beschäftigen, da die Entwicklung von Internetstandards und deren Umsetzung derartig schnell erfolgt. Dennoch verfolgt es ein traditionelleres Modell als etwa jenes informelle (wenn auch sehr effektive) Modell hinter der Internet Engineering Task Force (IETF).

Die meisten W3C-Empfehlungen haben eine Versionsnummer der Art Hauptnummer.Nebennummer, die von Softwareentwicklern bevorzugt wird, was vielleicht an den Ursprüngen der Organisation liegt. Das wird dann besonders deutlich, wenn wir uns die HTML-Spezifikationen anschauen; viele Versionen wurden veröffentlicht, und jede ist verschieden von den anderen. Dokumente, die irgend etwas enthalten, was über den allereinfachsten Inhalt hinausgeht, können nicht damit rechnen, zu mehr als einer Version der Empfehlung konform zu sein. Dies scheint bei einer Auszeichnungssprache schwer zu vermeiden zu sein, aber die Folge ist oft die, daß Standards nicht so wertvoll sind, wie sie sein könnten, wenn es möglich wäre, einen höheren Grad an Versionsunabhängigkeit zu bewahren.

Bei DOM macht es das W3C anders. Die Spezifikationen für DOM haben keine Versionen in dem Sinne, wie sie die HTML-Spezifikationen haben. Das neue Versionierungsmodell wird auch bei den Empfehlungen zu Cascading Style Sheets (CSS) benutzt, obwohl diese Spezifikationen nicht Gegenstand dieses Buches sind.

Die DOM-Spezifikation ist als Familie von individuellen Spezifikationen entwickelt worden, und diese Familie kann entlang zweier verschiedener Achsen beschrieben werden: Breite und Tiefe. Wenn wir an die Breite der Empfehlungen denken, können wir eine Familie mit vielen Eigenschaften beschreiben. In der Tiefe können wir eine Familie beschreiben, die weiter in Details vordringt und grundlegende Funktionalitäten abdeckt. Das W3C beschreibt funktionale Bereiche als Features, während es Detailtiefe als Levels beschreibt.

Spezifikations-Level

Es ist interessant, zuerst die Levels einer Spezifikation zu erläutern, da sie für viele Leute besonders verwirrend sein können. Man hört oft, daß Levels lediglich als ein seltsamer Name für den traditionellen Begriff der Versionen beschrieben werden, aber sie sind sehr verschieden davon. (Leider sind die DOM-Spezifikationen selbst dazu nicht immer sehr klar.) Mit der Verbesserung von Features in DOM werden neue Level definiert. Diese Ähnlichkeit zu traditionellen Versionen macht es gewiß einfacher, die beiden Konzepte zu verwechseln, aber es gibt einen wichtigen Unterschied: Eine Implementierung des zweiten Levels muß eine Implementierung des ersten enthalten; ein Fortschritt über den ersten Level hinaus bricht nicht mit der Kompatibilität von Code, der nur erwartet, daß er mit der älteren Variante der Spezifikation funktioniert.

Jeder Level der DOM-Spezifikationen geht durch die gesamte Breite der DOM-Familie, wie sie existierte, als sie definiert wurde (mit einer Ausnahme). Nachfolgende Level haben auch neue Features eingeführt. Implementierungen müssen zwar nicht alle Features von DOM implementieren, im allgemeinen aber diejenigen Features, die sie auf dem gleichen Level enthalten.

Als dieses Buch gerade geschrieben wurde, waren zwei DOM-Level in W3C-Empfehlungen definiert, während ein dritter von W3C-Arbeitsgruppen noch entwickelt wurde. Die Ur-Schnittstellen, die vor der DOM-Standardisierung von Browser-Implementierungen definiert waren, werden oft als »Level 0« bezeichnet. Die W3C-Spezifikation des Levels 1 besteht aus einer einzelnen Empfehlung, die nur zwei Features definiert, Kern und HTML. Dieser Level enthält allgemeine Unterstützung für HTML und die XML 1.0-Empfehlung, aber sonst nichts. Für den Level 2 hat das W3C die Spezifikation in sechs verschiedene Dokumente aufgebrochen. Das Kern-Feature wurde in die Kern- und XML-Features aufgeteilt, und es wurden von nun an Namensräume unterstützt. Zu den neuen Features des Levels 2 gehören ein Ereignismodell (hauptsächlich, wenn auch nicht ausschließlich, zum Gebrauch in Browsern), Cascading Style Sheets, Dokumenttraversierung, Bereichsangaben sowie ein vages Konzept von Dokument-Views. Seltsamerweise wurde das HTML-Feature für Level 2 nicht vollendet, und es gibt seit einer ganzen Weile keinen sichtbaren Fortschritt mehr.

Der dritte Level von DOM, der noch immer nur als Satz von Arbeitsentwürfen verfügbar ist, enthält zur Zeit nur vier Dokumente. Die Kern-, XML- und Ereignis-Features werden weiter verfeinert, aber das Interessanteste spielt sich bei den neuen Features ab. Die aktuellen Pläne umfassen neue Features für Schemata (zur Unterstützung von mindestens der DTD- und XML Schema-Sprachen), das Laden und Speichern von XML-Dokumenten sowie ein Objektmodell für XPath-Ausdrücke. (Wir werden XPath in Abfragen von XML mit XPath besprechen, aber es ist zu früh, das XPath-Feature von DOM als einsatzbereit anzusehen.)

Spezifikation der Features

Die in DOM definierten Features variieren von Level zu Level, wobei neue Features hinzukommen und alte Features in separate Features aufgeteilt werden. Ersteres ist kein Problem, weil Code, der mit einer Implementierung früherer Levels funktioniert, die neueren Features ganz einfach nicht brauchen wird. In der Praxis hat letzteres auch keine Schwierigkeiten bereitet, und sei es nur deshalb, weil Implementierungen auf Level 2 immer sowohl die Kern- als auch die XML-Features implementieren. Bei allen Implementierungen ist das einzig notwendige Feature der Kern.

Da die meisten Python-Implementierungen von DOM mindestens ein paar Features des Levels 2 enthalten und Level 3 nur in einem Entwurf existiert, sollten wir einen Blick darauf werfen, was jedes für Level 2 definierte Feature dem Anwendungsentwickler bietet.

Kern

Hierzu gehören Grundstrukturen, mit denen wohlgeformte XML-Dokumente offengelegt werden, ohne dabei DTD-Informationen offenzulegen. Insbesondere Entities, Notationen, Entity-Referenzen und Verarbeitungsanweisungen werden nicht zur Verfügung gestellt. Dies sind die Schnittstellen, mit denen wir uns in diesem Abschnitt befassen.

XML

Diese Feature-Menge fügt weitere Schnittstellen hinzu, mit denen Entity- und Notationsdeklarationen dargestellt werden, die in der Dokumenttyp-Deklaration vorkommen (aber nicht der Dokumenttyp selbst), sowie einiges an lexikalischen Informationen, die hilfreich bei der Erstellung eines modifizierten Dokuments sind, inklusive CDATA-Abschnitte, Entity-Referenzen und Verarbeitungsanweisungen.

Ereignisse

Dieses Feature ist insofern interessant, als es in mehrere spezifische Unter-Features aufgespalten ist. Alle Implementierungen, die irgendeine Art von Ereignissen unterstützen, müssen das grundlegende Ereignis-Feature unterstützen, aber nur jene speziellen Unter-Features, die für die Implementierung Sinn machen. Zu den Unter-Features gehört die Unterstützung verschiedener Klassen von Benutzerschnittstellen-Ereignissen und Dokument-Modifikationsereignissen.

Bereiche

Das Bereichs-Feature bietet Schnittstellen, die es ermöglichen, einen Teil eines Dokuments zu beschreiben, der nicht als Sequenz von Knoten dargestellt werden kann. Das kann besonders dann hilfreich sein, wenn ein Ausschnitt des Dokuments beschrieben wird, der vielleicht vom Benutzer hervorgehoben wird.

Traversierung

Hierbei wird die Traversierung über die Knoten eines Dokuments (oder über einen Dokumentteil) unterstützt, entweder in der Reihenfolge, in der sie im Dokument vorkommen, oder in Baumform, wobei die Anwendung einen Cursor entsprechend führt, daß bei der Traversierung Kindknoten, Elternknoten oder Geschwister besucht werden. Knoten können derart gefiltert werden, daß die Anwendung sich nicht um Knoten kümmern muß, für die sie kein Interesse zeigt.

Views

Eine vage Spezifikation, die mehrere Arten von Views auf ein Dokument bieten möchte. Dies ist nicht unbedingt nützlich.

StyleSheets

Eine abstrakte Schnittstelle zur Darstellung von Stylesheets. Sie ist nicht speziell an Cascading Style Sheets gebunden, sondern kann auch zur Darstellung anderer Arten von Stylesheets verwendet werden. Da sich alle Stylesheet-Sprachen erheblich unterscheiden, erlaubt sie nicht sehr viel Styling-Informationen.

CSS

Das CSS-Feature enthält Erweiterungen der Stylesheets-Schnittstelle, die wesentlich mehr Styling-Informationen bieten. Diese Schnittstellen bieten eine Menge Informationen über CSS-Stylesheets des Levels 2. Die Absicht dahinter ist, dieses Feature in Browsern und Editoren zu benutzen, die mit diesen Schnittstellen ihre Präsentation abhängig von Änderungen der Stylesheets anpassen sollten.

Außerhalb der DOM-Arbeitsgruppe für spezielle XML-basierte Sprachen wird an weiteren DOM-Features gearbeitet. Informationen darüber und die Spezifikationen der DOM-Arbeitsgruppe sind online unter Document Object Model (DOM) Technical Reports verfügbar.

  

<< zurück

vor >>