Proseminar SS04

DTD – Document Type Definition

Vortrag am 29.04.04

Robert Lukaschek

Gliederung

1. Einführung

2. Einbinden/Verknüpfung in XML-Datei

3. Grundaufbau einer DTD

3.1 Element

3.2 Attribut

3.3 Entities

4. Alternativen

5. Nutzen und Beipiele einer DTD

6. Quellen

1. Einführung in XML-Datei

Man unterscheidet in XML zwischen zwei Grundtypen, der DTD und dem eigentlichen XML-Dokument ( *.xml ).

In der DTD, der Document Type Definition, wird die Struktur des Dokuments beschrieben. Struktur bedeutet hier, dass genau festgelegt wird, in welcher Reihenfolge die Elemente in der XML-Datei zu erscheinen haben und wie diese untereinander verschachtelt sein können. Im allg. kann man sagen das es sich hier um eine Formvorlage für eine Art Textdokument handelt.

Das XML-Dokument füllt die in der DTD definierte Gliederung der Daten mit entsprechenden Inhalten. Hier werden den Elementen die Werte zugewiesen. Eine XML-Datei kann wohlgeformt oder gültig sein. Wohlgeformt heißt, dass die in der XML-Spezifikation definierten Regeln korrekt angewandt worden sind. Gültigkeit setzt neben der Wohlgeformtheit auch die Existenz einer DTD voraus. Dabei muss die in der XML-Datei verwendete Struktur mit der aus der DTD übereinstimmen.

2. Einbinden in XML-Datei

Eine DTD kann entweder intern in dem XML-Dokument mit angegeben werden, oder separat in einer Datei (extern) abgelegt werden. Diese ist dann nicht auf eine XML-Datei beschränkt. Mehrere XML-Datein der gleichen Art können also die gleiche externe DTD verwenden. Zur Erstellung einer solchen Datei kann man mit jedem beliebigen Texteditor arbeiten. Inhalt einfach unter dem Dateiende *.dtd speichern und fertig.

2.1 interne DTD

kurzes Beispiel:

<?xml version='1.0'?>
<!DOCTYPE buch [
...
...
... ]>
<buch> Inhalt </buch>

2.2 externe Datei

kurzes Beispiel:

<?xml version='1.0'?>
<!DOCTYPE buch SYSTEM 'buch.dtd'>
<buch> Inhalt </buch>

Das 2. Beispielprogramm beginnt mit der optionalen Anweisung <?xml>, die angibt, welche XML-Version verwendet wird. Danach wird über die Anweisung die DTD angegeben, die für die Verarbeitung des Dokuments verwendet werden soll. In diesem Fall sollte dem Browser eine DTD namens buch.dtd zur Verfügung stehen, damit er feststellen kann, ob das <buch>-Tag innerhalb des Dokumentes gültig ist.

3. Grundaufbau einer DTD

DTD unterscheiden sich in Kommentare und verschiedene Grundtypen. Kommentare werden mit <!-- eingeleitet und enden mit -->. Dazwischen darf nicht „--“ stehen. Ansonsten dürfen Kommentare an alle Stellen, außer innerhalb von Markierungen und im XML-Dokument vor der ersten Deklaration (<?...>), gesetzt werden.

Jeder Grundtyp mit der Zeichenfolge ,,<!'' begonnen und mit ,,>'' beendet. Wie und womit die Struktur definiert wird folgt in den nächsten Abschnitten. Es stehen dazu ein Reihe von Typen zur Verfügung, von denen hier nur die wichtigsten drei besprochen werden.

3.1 Element

Der wohl bedeutendste Typ ist das Element. Hierdurch wird die Struktur des gesamten Dokuments bestimmt. Es gibt in jeder DTD und selbstverständlich auch in jeder XML-Datei ein Wurzelelement, welches alle anderen Elemente umschließt.

Definiert wird ein Element in der DTD wie folgt:

<!ELEMENT Name Inhalt>

Der Elementtyp gibt an, welchen Inhalt das Element hat. Zur Veranschaulichung der Definition und Verwendung von Elementen wird hier das Beispiel eines Buches aufgegriffen.

<!ELEMENT buch (autor+, titel, kapitel+)>
<!ELEMENT autor #PCDATA>
<!ELEMENT titel (haupttitel, untertitel?)>

Es gibt in jeder DTD und selbstverständlich auch in jedem XML-Dokument ein Wurzelelement, welches alle anderen Elemente umschließt. Das Wurzelelement ist hier „buch“. Der Inhaltsabschnitt kann verschiedenen Typen entsprechen. Die beiden am meisten verwendeten sind im oberen Beispiel aufgeführt.

Wenn ein Tag einen oder mehrere Untertags besitzt, kann der Inhalt ein Satz Grammatikregeln sein, welche die Reihenfolge und Verschachtelungsgesetze einer Gruppe von Untertags des definierten Elements festlegen.

Oft wird die Reihenfolge einfach dadurch definiert, dass die entsprechenden Element geordnet und durch Kommas getrennt aufgezählt werden.

Durch Auswahlregeln bekommt der Autor allerdings mehr Flexibilität, da er nun die Wahl aus einer Gruppe von gültigen Elementen hat. Festgelegt wird dies durch einen senkrechten Balken ( | ). Bsp.: bei A, B, ( C | D) kann man nach dem zweiten Komma nun C oder D angeben.

Zusätzlich existieren noch die besonderen Zeichen „+“, „*“ und „?“. Die ersten Beiden „+“ und „*“ geben an, wie oft ein Element verwendet werden darf. Bei „+“ muss es mindestens einmal vorkommen und bei „*“ ist die Verwendung völlig wahlfrei (nicht oder öfter). Das Sonderzeichen „?“ gibt an, dass das Element entweder nicht oder max. einmal vorkommen darf.

Des weiteren existiert der Typ #PCDATA. Dieser zeigt an, das dieses Element in der XML-Datei mit einer Zeichenkette gefüllt werden muss.

Ein weiterer Typ wird mit #Empty bezeichnet. Dieser definiert ein Zeichen ohne Inhalt. Beispiel wäre hier das Tag <p> oder <br>, in welchen eine Funktion folgt aber kein Inhalt.

3.2 Attribut

Attribute beziehen sich auf genau ein Element, um für dieses zusätzliche Informationen bereitzustellen.

<!ATTLIST Elementname Attributname Attributtyp>

Der Elementname muss einem schon vorher definierten Element entsprechen. Bei dem Attributname kann eine beliebige Anzahl von Attributen für das Element definieren. Der jeweilige Attributname besteht aus einer beliebigen Zeichenkette.

Der Typ eines Attributs kann entweder eine Zeichenkette, ein Token-Typ oder ein Aufzählungstyp sein. Der Zeichenkettentyp erlaubt dem Benutzer der DTD, dem Attribut einen beliebigen String zuweisen. Die Menge der Token-Typen besteht aus vom XML-Standard definierten Typen, denen man Zahlen, Referenzen oder ähnliches zuweisen kann. Beim Aufzählungstyp kann der Benutzer dem Attribut einen Wert aus der jeweils zu deklarierenden Liste zugewiesen.

Bsp.: <!ATTLIST autor geschlecht (m | w) ’m’>

Dem Autor kann jetzt im XML-Dokument entweder das Geschlecht ,m’ (für männlich) oder ,w’ (für weiblich) zugeordnet. Wird keine explizite Zuweisung vorgenommen, so wird der Standardwert, hier ‚m’ für das entsprechende Element angenommen.

<buch>
<autor geschlecht=’m’>Max Mustermann</autor> ...
</buch>

In diesem Fall wurde dem Autor Max Mustermann das Geschlecht männlich zugewiesen. Hier hätte auch wegen der Standardeinstellung auf männlich auf das Attribut verzichtet werden können.

Einige weitere Informationen müssen zu den Attributen unbedingt noch gemacht werden. So kann ein Attribut immer nur für ein Element definiert werden. Weiterhin kann man Attributen auch Vorgaben machen. So kann man den Wert eines Attributs fest einstellen oder die Angabe eines Attributs explizit fordern. Realisiert wird dies durch einen zusätzlichen Parameter bei der Definition. Dazu werden die Schlüsselwörter #REQUIRED (notwendig), #IMPLIED (impliziert) oder #FIXED (fest) verwendet. Bei #REQUIRED muss das Attribut immer angegeben werden, während #IMPLIED bedeutet, dass es keinen Vorgabewert gibt. Hat ein Attribut den Wert #FIXED, so folgt diesem der festgelegte Wert des Attributs. Dann muss das Attribut in der XML-Datei nicht explizit angegeben werden.

3.3 Enitities

Ein Entity wird definiert durch ein <!entity>-Tag in einer XML-DTD. Zunächst muss innerhalb des Tags der Entity-Name und –Wert angegeben werden, dann wird festgelegt ob es sich um ein allgemeines oder ein Parameter-Entity handelt.

<!ENTITY name wert>
<!ENTITY % name wert>

Die erste Version erzeugt ein allgemeines Entity, die zweite wegen des Prozentzeichens ein Parameter-Entity. Bei beiden Arten ist der Name eine einfache Zeichenfolge, die nur die Einschränkung besitzt, dass sie nicht mit xml beginnen darf (egal ob groß- oder kleingeschrieben).

Der Entity-Wert ist entweder eine Zeichenkette in Anführungszeichen oder ein Verweis auf ein anderes Dokument, das den Wert des Entity enthält. Bei diesen externen Entity-Werten findet man entweder das Schlüsselwort SYSTEM, gefolgt von der URL des Dokumentes, das den Entity-Wert enthält, oder das Schlüsselwort PUBLIC, gefolgt von dem formalen Namen und der URL des Dokumentes.

Bsp.:

<!ENTITY frucht ’Mango oder ähnliche exotische Früchte’>
<!ENTITY fließtext SYSTEM ’http://server.com/fließtext.txt’> <!ENTITY % HTMLlat1 PUBLIC ’-//W3C//ENTITIES Latin 1 for XHTML//EN’ ’xhtml-lat1.ent’>

4. XML-Schema

Eine Alternative zu DTDs ist XML Schema. XML Schema selbst erweitert die Sprachmöglichkeiten von DTDs erheblich. Es formuliert auch wieder Regeln zur Einstellung von XML-Dokumenten, hat jedoch eine Anzahl von zusätzlichen Möglichkeiten. Man hat so die Möglichkeit auf mehr Datentypen (Integer, Datum) zugreifen zu können oder Namensräume deklarieren zu können.

5. Nutzen und Beipiele einer DTD

Letztendlich noch ein paar Worte zu Anwendungen von DTDs

Nutzen einer DTD

Der Aufwand für die Erstellung einer DTD kann rasch einen größeren Umfang annehmen. Im folgenden finden Sie einige Hinweise, wann und wo man eine DTD verwenden sollte bzw. wann sich der Aufwand für die Erstellung einer DTD nicht lohnt.

Mögliche Gründe für eine DTD

-Projektdokumentation: Eine DTD dokumentiert die Struktur der Xml-Dokumente genauer, als dies aus dem jeweiligen Xml-Dokument hervorgeht. Man denke an Attribute, die genau einen Wert aus einer Liste annehmen dürfen - die Liste steht nur in der DTD, jedes Attribut kennt höchstens einen Wert.

-Verwenden von Techniken, die zwingend eine DTD benötigen: Attribute mit Default-Werten, die im Xml-Dokument weggelassen werden können und vom Parser dennoch mit dem Default-Wert eingefügt werden. Verwenden von Attributen des Typs ID / IDREF usw. sowie von Auflistungstypen. Alle Entity-Typen können nur in einer DTD deklariert werden. Verwenden von INCLUDE / IGNORE.

-Regelmäßige Erstellung großer Xml-Dokumente, welche denselben Regeln, damit derselben DTD genügen müssen. Werden wiederholt, womöglich von verschiedenen Personen, Xml-Dokumente erstellt, die zwingend gleichartig aufgebaut sein müssen, so ist die Erstellung und Pflege einer DTD Pflicht, gegen welche jedes Xml-Dokument validiert wird.

-Wiederholtes Verarbeiten von Daten, die an anderer Stelle erstellt wurden: Jeder strukturierte Datenaustausch läßt sich über Xml abwickeln, ein Xml-Dokument kann per Mail empfangen oder vom Versender einfach zum Download auf einer Website bereitgestellt werden. Hier wird man die Anforderungen an die erhaltenen Dokumente nur selten ändern und sie in einer vielleicht über die eigene Domain veröffentlichten DTD festschreiben. Sowohl die Ersteller als auch die Empfänger der Xml-Dokumente können rasch prüfen, ob das versandte bzw. erhaltene Dokument der DTD genügt.

-Weiterverarbeitung der Xml-Quelle mit XSLT: XSLT verwendet templates mit match-Attributen, die auf Xml-Elemente verweisen. Fehlt in einem Xml-Dokument ein Element, welchem im XSLT-Dokument ein template zugeordnet ist, so ist dies kein Fehler, es führt nicht zu einem Abbruch. Es wird lediglich das zugehörige template nicht beachtet und nicht ausgeführt. Damit können Schreibfehler im Xml-Dokument, bei welchen bsp. ein wichtiges Element sowohl beim Öffnen als auch beim Schließen konsistent anders notiert wurde, zu lückenhaften Ausgaben führen, sie stellen damit eine nur sehr schwer ermittelbare Fehlerquelle dar. Eine DTD kann dieses Problem vermeiden, da im Xml-Dokument nicht erlaubte Elementnamen sofort zu einem Abbruch führen.

Situationen, in den sich die Mühe einer DTD nicht lohnt

-Erstellen einer DTD, die nur für ein einziges Dokument benötigt wird. Eine DTD ist erst dann wirklich sinnvoll, wenn mehrere Dokumente basierend auf einer DTD erstellt werden. Ausnahme: Erstellen einer DTD zu Lernzwecken.

-Zur Erarbeitung von XSLT: Für das Lernen von eXtensible Stylesheet Transformation Language, der Transformationssprache, mit der man ein Xml-Dokument in ein anderes Xml-Dokument oder in reinen Text transferieren kann, ist die Erstellung einer DTD für das Xml-Quelldokument nicht notwendig und auch nicht sinnvoll. XSLT kann jedes wohlgeformte XML-Dokument verarbeiten, die zusätzliche Validität der Xml-Quelle ist nicht notwendig. fehlt eine DTD, kann man dem Xml-Dokument rasch neue Elemente hinzufügen und die Auswirkungen auf das Transformationsergebnis testen, ohne die Validität des Dokuments zu gefährden.

-Nur eine Person arbeitet mit den Xml-Dokumenten und fügt Elemente und Attribute ad hoc hinzu. Auf eine Dokumentation wird derzeit verzichtet, da sich die Struktur der Xml-Dokumente ständig ändert.

6. Quellen

Bücher:

HTML & XHTML – Chuck Musciano & Bill Kennedy

Internet:

http://www.w3.org/TR/2000/REC-xml-20001006