Deklaration von Elementen und Attributen

(Auszug aus "Perl & XML" von Erik T. Ray & Jason McIntosh)

Wenn Ihnen der Status der Wohlgeformtheit nicht genügt und Sie statt dessen eine genauere Kontrolle der Struktur eines Dokuments benötigen, dann sollten Sie die Grammatik Ihrer Markup-Sprache in einer DTD formulieren. Durch diese Regeln wird aus Ihrem Markup eine formale Sprache, die von keiner internationalen Organisation besser dokumentiert werden könnte. Mit einer DTD kann man unmittelbar sagen, ob ein Dokument die DTD erfüllt. Wir sagen dann auch, daß das Dokument ein gültiges Beispiel des Dokumenttyps ist.

Um die Sprache zu beschreiben, enthält die DTD im wesentlichen zwei verschiedene Arten von Deklarationen. Da ist zunächst einmal die Elementdeklaration. Sie führt einen neuen, erlaubten Elementnamen ein. In einer speziellen Template-Sprache gibt sie außerdem an, was innerhalb des Elements erlaubt ist. Einige Beispiele:

<!ELEMENT Sandwich ((Schinken | Kaese)+ | (Erdnussbutter, Marmelade)), Wuerze+, Gurken?)>
<!ELEMENT Gurken EMPTY>
<!ELEMENT Wuerze (PCDATA | Senf | Ketchup )*>

Der erste Parameter gibt den Elementnamen an. Der zweite Parameter ist ein Template, eine Beschreibung des Inhaltsmodells (»content model«), also der im Element erlaubten Daten in runden Klammern, oder das Schlüsselwort EMPTY. Ein solches Inhaltsmodell ist nichts anderes als ein regulärer Ausdruck. Der wesentliche Unterschied besteht darin, daß man ganze Elementnamen statt einzelner Symbole als Token benutzt. Ferner wird das Komma als Trennzeichen für die verschiedenen Elemente verwendet. Jedes im Inhaltsmodell vorkommende Element sollte in der DTD deklariert sein.

Neben der Deklaration der Elemente gibt es auch noch die Deklaration der Attributlisten. Damit kann man einem Element eine Menge optionaler oder erforderlicher Attribute zuweisen. Auch eine gewisse Kontrolle der Attributwerte ist möglich, die zur Verfügung stehenden Restriktionen sind aber nicht sehr umfangreich. Schauen wir uns auch hierzu ein Beispiel an:

<!ATTLIST Sandwich
   id ID #REQUIRED
   preis CDATA #IMPLIED
   geschmack CDATA #FIXED "prima"
   name (Legato | Schinken-Kaese | Solo | Duo ) 'Solo'
>

Eine Attributdeklaration besteht im wesentlichen aus drei Teilen: einem Namen, einem Datentyp und einer Feinspezifikation. Unser Beispiel deklariert die Attribute des Elements <Sandwich>. Das erste mit Namen id hat auch den Typ ID. Damit ist gemeint, daß der Attributwert ein unter allen anderen Attributwerten desselben Typs eindeutiger String ist. Die Eindeutigkeit gilt allerdings nur innerhalb des Dokuments. Das Schlüsselwort #REQUIRED gibt an, daß dieses Attribut nicht fehlen darf. Das zweite Attribut namens preis hat den Typ CDATA. Wegen des Schlüsselworts #IMPLIED ist es optional. Das dritte Attribut namens taste ist fix, es hat immer den Wert "prima". Man kann diesen Wert nicht weglassen: Alle <Sandwich>-Elemente erben ihn automatisch. Schließlich gibt es noch das Attribut name, das nur Werte aus einer vorbereiteten Liste annehmen darf und einen Standardwert 'Solo' besitzt.

Obwohl es sie schon lange gibt und beide mit großem Erfolg eingesetzt wurden, haben sowohl Element- als auch Attributdeklarationen wesentliche Nachteile. Die Syntax des Inhaltsmodells ist relativ unflexibel. Zum Beispiel ist es überraschend schwierig, das folgende zu formulieren: »Dieses Element enthält jedes der Unterelemente A, B, C und D, aber in beliebiger Reihenfolge.« (Versuchen Sie es einmal selbst!) Außerdem gibt es keine leistungsfähigen Einschränkungen der Textdaten. Man kann zum Beispiel nicht sicherstellen, daß ein Element <Datum> auch tatsächlich ein Datum enthält und nicht etwa einen Straßennamen. Die dritte und vielleicht wichtigste Tatsache: DTDs können nicht mit Namensräumen kombiniert werden. Wenn man Elemente deklariert, dann muß man alle Elemente deklarieren, die man irgendwo im Dokument zu verwenden beabsichtigt, nicht nur einige. Möchte man beispielsweise die Möglichkeit haben, einige Elemente aus einem anderen Namensraum zu importieren, dann kann man nicht gleichzeitig mit einer DTD zur Validierung arbeiten – zumindest nicht ohne eine Fixierung des Präfix und ohne eine Kombination verschiedener DTDs, was ohnehin nicht besonders gut funktioniert.

  

  

<< zurück vor >>

 

 

 

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

Copyright © 2003 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 "Perl & XML" 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