DTD - Dokumenttyp-Definitionen
Die DTD, eine Definition eines Dokumententyps, ist eine Möglichkeit festzulegen, wie eine Baumstruktur aufgebaut sein muss, indem zu jedem Element (Tag) festgeschrieben wird, ob, welche und wie viele Kind-Elemente enthalten sein dürfen oder müssen. Eine ihr folgende XML- Instanz muss exakt nach diesem Muster aufgebaut sein muss.
Eine DTD sollte möglichst genau und streng das zu Grunde liegende Konzept abbilden, da dies eine wesentliche Voraussetzung für das Erstellen guter Instanzen darstellt.
DTDs sollten immer als externe Ressourcen erstellt werden, können aber auch in der Instanz selber stehen. Dies ist aber ausdrücklich NICHT empfehlenswert.
Die Datei wird unter einem beliebigen Namen mit dem Suffix .dtd abgespeichert.
Folgende syntaktische Regeln müssen beachtet werden:
- Jedes in einer Instanz notwendige Tag muß durch eine <!ELEMENT …> Deklaration explizit eingeführt werden.
- In dieser Deklaration folgt zunächst der Name des Tags, in exakt der gleichen Schreibung, in der er in der Instanz verwendet werden soll.
<!ELEMENT bildersammlung (name?, lokalisation, bild+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT lokalisation EMPTY>
<! ATTLIST lokalisation
url CDATA #IMPLIED
postal CDATA #IMPLIED
>
<!ELEMENT bild (titel, url, abstract*, person+, bauwerk+)>
<!ELEMENT titel (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT person (bezeichnung+)>
<!ELEMENT bauwerk (bezeichnung+)>
<!ELEMENT bezeichnung (#PCDATA)>
Das Content Modell oder Inhaltsmodell ist eine Spezifikationen, die Reihenfolge und Umfang der Kindelemente festlegt:
- In Form einer durch Kommata geordneten Liste werden alle Tags, die in dem betroffenen enthalten sein dürfen, in der Reihenfolge angegeben, in der sie vorkommen müssen.
- Steht hinter dem Namen kein Sonderzeichen, muß das Tag genau einmal vorkommen.
- Steht hinter dem Namen ein Pluszeichen, bedeutet dies, daß das Tag mindestens einmal vorkommen muß, aber auch öfter vorkommen kann.
- Steht hinter dem Namen ein Fragezeichen, bedeutet dies, daß das Tag einmal vorkommen darf, aber nicht muß.
- Steht hinter dem Namen ein Sternchen – ‚*‘, bedeutet dies, daß das Tag mehrmals vorkommen darf, aber auch ganz fehlen darf.
- Die spezielle Konstruktion #PCDATA teilt mit, daß an dieser Stelle beliebige Daten stehen dürfen. (PCDATA = „Parseable Character Data“)
- EMPTY als Keyword im Content Model bedingt, dass ein solches Tag nur aus einem Start-Tag besteht und keine Information umschlossen wird. Diese Tags enthalten häufig Attribute, die spezifische Information beinhalten.
Hierarchisierung
Elemente können/müssen über beliebig viele Ebenen gestaffelt sein. In DTDs tritt eine deutliche Hierarchisierung auf: ein Baum mit Eltern,- Kind,- und Geschwisterelemente (Vorfahren und Nachfahren).
Je mehr Hierarchieebenen eine XML-Datei aufweist, umso komplexer und genauer ist die Beschreibung der Ressource.
Beispiel:
streng genommen ist ‚Eiffelturm‘ nicht das Bauwerk selbst sondern es handelt sich um eine Bezeichnung für dieses. Ebenso verhät es sich mit ‚Mona Lisa‘. Diese Vereinbarung kann in das Konzept einbezogen werden.
Es folgt eine Erweiterung der Instanz:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE bildersammlung SYSTEM "bild01.dtd">
<bildersammlung>
<name>Neue schöne Bilder</name>
<lokalisation url=http://www.bilder.de/>
<bild>
<titel>Mona Lisa vor dem Eiffelturm</titel>
<url>http://www.woauchimmer.de</url>
<person>
<bezeichnung>Mona Lisa</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Eiffelturm</bezeichnung>
</bauwerk >
</bild>
<bild>
<titel>Ritter, Burgen, Adel</titel>
<url>http://www.beispielseite.de</url>
<person>
<bezeichnung>byzantinische Kaiserin</bezeichnung>
</person>
<person>
<bezeichnung>Ritter des 13.Jhd</bezeichnung>
</person>
<person>
<bezeichnung>fränkischer Edelmann</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Wasserburg</bezeichnung>
</ bauwerk >
</bild>
<bild>
....
</bild>
</bildersammlung>
DTD Attribute
Codierung der Attribute
<!ELEMENT bildersammlung (name?, lokalisation, bild+)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT lokalisation EMPTY>
<!ATTLIST lokalisation
url CDATA #IMPLIED
postal CDATA #IMPLIED>
<!ELEMENT bild (titel, url, abstract*, person+, bauwerk+)>
<!ELEMENT titel (#PCDATA)>
<!ELEMENT url (#PCDATA)>
<!ELEMENT abstract (#PCDATA)>
<!ELEMENT person (bezeichnung+)>
<!ELEMENT bauwerk (bezeichnung+)>
<!ELEMENT bezeichnung (#PCDATA)>
Enthält ein Element Attribute, so werden diese durch eine <!ATTLIST … > Definition festgelegt.
Sie legt zunächst fest, für welches Element eine Attributliste definiert wird. Danach folgen für jedes Attribut, das innerhalb dieses Elements verwendet werden soll, mindestens zwei, oft auch mehere Angaben, und zwar:
- Der Name des Attributes,
- sein Typ (CDATA = Character Data) und optional
- weitere Angaben, die zum Teil von verschiedenen Attributtypen erwartet werden; häufig aber auch Schlüsselwörter die vorschreiben, wie das Attribut verwendet werden soll. Über die Keywords REQUIRED (obligatorisch) und IMPLIED (optional) können die Verbindlichkeiten für Attribut-Zuweisungen in einem Element festgelegt werden. Das Attribut @identifier des Typs ID muss (#REQUIRED), das Attribut @zustand kann (#IMPLIED) im <bild>-Tag gesetzt werden.
Mittels der obigen DTD ist beispielsweise diese Instanz validierbar:
<!DOCTYPE bildersammlung SYSTEM "beispiel.dtd">
<bildersammlung>
<name>Neue schöne Bilder</name>
<lokalisation url=http://www.bilder.de
postal="Musterstadt"/>
<bild>
<titel>Mona Lisa vor dem Eiffelturm</titel>
<url>http://www.woauchimmer.de</url>
<abstract>Hier steht die Mona Lisa vor
dem Eiffelturm</abstract>
<person>
<bezeichnung>Mona Lisa</bezeichnung>
</person>
<bauwerk>
<bezeichnung>Eiffelturm</bezeichnung>
</bauwerk>
</bild>
<bild>
....
</bild>
<bild>
....
</bild>
</bildersammlung>