2000
2000
Bei der Verwendung von HTML werden die
meisten Online-Autoren nur selten oder gar nicht mit der
HTML-DTD in Berührung kommen. Entweder
benutzen sie einen Editor, der die Komplexität von
HTML vor ihnen verbirgt oder sie schreiben ihre
Web-Seiten mit einem normalen Texteditor, ohne besonders auf
korrektes
, also DTD-konformes
HTML zu achten. Aus dieser Sichtweise kann man
nun die Frage stellen, wozu eine DTD
überhaupt notwendig ist. Die Antwort lässt sich
mit dem zuvor vermittelten SGML-Wissen leicht
geben.
Eine DTD beschreibt den strukturellen
Aufbau und die logischen Elemente einer Klasse von
Dokumenten, genannt
Dokumenttyp. Bereits diese Beschreibung
lässt den Sinn der HTML-DTD recht
fragwürdig erscheinen, behauptet sie doch nichts anderes,
als dass alle Dokumente im Web vom gleichen
Typ seien. Tatsächlich enthalten
HTML-Instanzen aber eine Vielzahl
verschiedenartiger Dokumente. Von wissenschaftlichen Arbeiten
über Gedichte, Kochrezepte und Homepages bis zu
Einkaufskatalogen ist
alles vertreten. Doch es würde wohl niemand behaupten,
dass all diesen Texten die gleiche Struktur zu Grunde
läge oder dass sie alle aus denselben logischen
Elementen bestünden. Warum werden sie aber alle durch die
gleiche DTD repräsentiert? Dies ist
sicherlich durch die historische Entwicklung
bedingt. Glücklicherweise spielt dies inzwischen
keine Rolle mehr, denn nun gibt es ja XML als
Ausweg
.
Den Einstieg soll ein leichtes Beispiel für einen sehr einfachen Dokumenttyp bieten: Eine DTD für E-Mails.E-Mail Im Wesentlichen besteht eine E-Mail aus
Subject) sowie
In der XML-Fassung sieht dies folgendermaßen aus:
<!-- E-Mail-DTD Version 1 -->
<!ELEMENT email (empfaenger, absender,
thema, nachricht) >
<!ELEMENT empfaenger (#PCDATA)>
<!ELEMENT absender (#PCDATA)>
<!ELEMENT thema (#PCDATA)>
<!ELEMENT nachricht (#PCDATA)>Für dieses Beispiel braucht man die Erklärung kaum, man kann die DTD direkt lesen: Eine email besteht aus einem empfaenger, einem absender, einem thema sowie einer nachricht, und zwar in dieser Reihenfolge. Alle diese Elemente enthalten ihrerseits ausschließlich reinen Text, hier Parsed Character Data (PCDATA) genannt.
So weit so gut, doch wie sehen dann die E-Mails aus? — Wenn man sich erst einmal an die von SGML geerbte Schreibweise mit den spitzen Klammern gewöhnt hat, fällt auch das Lesen der Instanzen nicht schwer.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE email SYSTEM "email1.dtd">
<email>
<empfaenger>Henning Behme</empfaenger>
<absender>Stefan Mintert</absender>
<thema>Aus dem Urlaub zurück?</thema>
<nachricht>
Hallo Henning,
ich hoffe, Du bist bald aus dem Urlaub zurück und
hast auch an dem XML-Buch gearbeitet.
Bis bald,
Stefan.
</nachricht>
</email>Natürlich ist dieses Beispiel verbesserungswürdig. Beispielsweise ist hier die Frage, wie Empfänger und Absender zu notieren sind, völlig ausgeklammert. In der obigen Schreibweise wird ein Mailprogramm sicher Schwierigkeiten bekommen, den Adressaten ausfindig zu machen. Es ist aber kein Problem, die DTD so zu erweitern, dass eine Instanz sowohl den Namen einer Person als auch deren E-Mail-Adresse enthalten kann (oder muss).
Man könnte nun die Frage stellen,
wozu die DTD überhaupt nützlich
ist. Die obige Instanz kann man auch ganz gut ohne
DTD lesen. Tatsächlich erlaubt
XML, eine Instanz ohne DTD zu
schreiben. Bedingung dafür sind gewisse Eigenschaften des
Dokuments, die später genau erklärt
werden. Sobald man aber mehrere
gleichartige Texte schreibt, wie zum Beispiel eine Reihe von
E-Mails, dann dient eine DTD als Muster,
als Vorlage. Ein Editor kann dieses Muster schon beim
Schreiben mit dem aktuellen Dokument vergleichen und auf
strukturelle Fehler hinweisen. Dies könnte etwa ein
fehlender Empfänger sein. Wenn man keine DTD
benutzt, kann man von keinem Programm erwarten, dass es
weiß
, welche Bestandteile eine Instanz besitzen
muss.
Ein ganz wesentlicher Punkt ist bisher vernachlässigt worden. Vielleicht ist es Ihnen schon aufgefallen, dass das E-Mail-Beispiel recht unflexibel ist. Ein Verfasser hat keine Möglichkeit, von den vorgegebenen Bestandteilen einige wegzulassen oder weitere hinzuzufügen. Für den Fall, dass er die Nachricht auch noch an weitere Personen schicken möchte, wäre es doch schön, wenn die DTD weitere Adressaten zuließe, die eine Kopie erhalten sollen. Dies ist leicht getan:
<!-- E-Mail-DTD Version 2 -->
<!ELEMENT email (empfaenger, kopieAn*,
absender, thema, nachricht)>
<!ELEMENT empfaenger (#PCDATA)>
<!ELEMENT kopieAn (#PCDATA)>
<!ELEMENT absender (#PCDATA)>
<!ELEMENT thema (#PCDATA)>
<!ELEMENT nachricht (#PCDATA)>Hier ist das Element kopieAn neu
hinzugekommen. Das Besondere ist hier der Stern hinter dem
Elementnamen. Er bedeutet, dass das Element beliebig
oft auftauchen darf, egal ob es überhaupt nicht oder ein Dutzend
mal erscheint. Das heisst, dass die oben gezeigte Mail
immer noch zu dieser neuen DTD passt
!
Jetzt ist aber auch die folgende Instanz zulässig.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE email SYSTEM "email2.dtd">
<email>
<empfaenger>Henning Behme</empfaenger>
<kopieAn>Fernando Pereira / AWL</kopieAn>
<kopieAn>Produktion / AWL</kopieAn>
<absender>Stefan Mintert</absender>
<thema>Status: XML-Buch</thema>
<nachricht>
Hallo Henning,
mit dem XML-Buch läuft bei mir alles prima!
Wie sieht es bei Dir aus?
Bis bald,
Stefan.
</nachricht>
</email>Copyright 1998-2004 Henning Behme & Stefan Mintert. Alle Rechte vorbehalten.
Optimiert für HTML- & CSS-Browser. Einige Funktionen setzen JavaScript und W3C-DOM voraus. Bestes Ergebnis mit Mozilla und Opera. Wir unterstützen Standards!
Diese Online-Veröffentlichung wurde automatisch aus XML-Quellen mit XSLT generiert.
Sie brauchen XML-Beratung oder Software-Entwicklung? Wenden Sie sich an Linkwerk! Wir sind spezialisiert auf XML-Verarbeitung, XML-Beratung, DTD/XML-Schema-Entwurf, XSLT-Programmierung, Datenaustausch und -konvertierung (u.a. XML, Office-Formate, WordML, Office Open XML, AECMA/ATA, XSL-FO, PDF, DITA)
