XML in der Praxis - Auswahl einer Mehrzweck-DTD

13.1 Auswahl einer Mehrzweck-DTD

Ob Sie eine fremde DTD verwenden sollten, hängt von verschiedenen Faktoren ab. Wenn Sie Texte für eine Firma oder eine andere Institution schreiben, so kann es sein, dass Ihnen einfach eine DTD vorgegeben wird, an die Sie sich halten müssen. In diesem Fall haben Sie keine Wahl.

Wenn Sie jedoch daran denken, für Ihre eigenen Zwecke eine DTD zu übernehmen, so gibt es einige Dinge zu beachten. Zuerst sollten Sie natürlich bedenken, welche Absicht Sie mit Ihrem XML-System verfolgen. Die Maßstäbe, die Sie an eine selbst entwickelte DTD anlegen, sollten auch für eine fremde DTD gelten. Ein wesentlicher Unterschied besteht darin, dass eine fremde DTD niemals so gut an Ihre Wünsche angepasst sein kann, wie Ihre eigene. Es wird sich also um eine Mehrzweck-DTD handeln.

Mehrzweck-DTDs erleichtern die Verarbeitung, da beispielsweise ein Style Sheet nur einmal geschrieben werden muss.

Die Auswahl an XML-DTDs wird schnell grösser. Aufgrund der Unterschiede zwischen XML und SGML können Sie in der Regel nicht direkt eine SGML-DTD verwenden. Für SGML gibt es bereits eine Reihe guter Mehrzweck-DTDs, wie zum Beispiel Docbook, Linuxdoc, Qwertz u.v.a. Einige davon, wie die Docbook, gibt es bereits in einer XML-Variante.

Wenn Sie sich daran machen, eine DTD auszusuchen, achten Sie auf folgende Punkte:

Welche Informationen gehen durch die Mehrzweck-DTD im Gegensatz zu einer eigenen verloren? Können Sie diesen Informationsverlust in Kauf nehmen?
Wie offen ist die DTD? Kann man den Informationsverlust vielleicht abmindernIn HTML ist dies möglich. Zwar ist HTML eine Mehrzweck-DTD, die gar keine spezifische Informationen über den Inhalt enthält, aber durch die Einführung des class-Attributs kann der Verfasser wenigstens optionale Informationen hinzufügen. Das ist allerdings auch eine Form der DTD durch die Hintertür: HTML wurde nachträglich durch class erweitert, um das zu enthalten, was Generic Markup ausmacht (siehe Kapitel 2). Die logische Information, von der zu Beginn die Rede war, sollte nicht in beliebig benennbaren Attributen versteckt, sondern in einer DTD formal definiert sein.?
Welche Formatierer bzw. Konverter gibt es für die DTD schon? Erfüllen diese Ihre Bedürfnisse?
Welchen Zeit-/Kostenaufwand würde es bedeuten, eine eigene DTD nebst passender Formatierer bzw. Konverter zu entwickeln?
Wie groß ist der Aufwand, die Endbenutzer in die Mehrzweck-DTD einzuarbeiten? Dies schließt auch die zu verwendenden Editoren ein. Ist dieser Aufwand geringer oder größer als bei einer eigenen DTD?

Wie Sie diese Fragen und deren Antworten bewerten, sei Ihnen überlassen. Dies kann von Fall zu Fall unterschiedlich sein. Auf eine tiefere Diskussion verzichten wir hier, da wir in diesem Buch zeigen möchten, wie man XML selbst macht und nicht nur nachmachtSonst könnte man gleich bei HTML bleiben..

Ganz anders ist die Situation zu bewerten, wenn Sie XML für den Datenaustausch einsetzen (z.B. B2B-E-Commerce). In diesem Fall ist unbedingt zu berücksichtigen, welche DTDs es für die jeweilige Branche schon gibt und ob die Parteien, mit denen Sie Daten austauschen möchten, schon bestimmte DTDs (oder Schemata) verwenden. Beim Datenaustausch muss es darum gehen, eine Einigung über das gemeinsame Vokabular der Elemente zu finden. So gesehen handelt es sich um einen besondere Situation, da Sie nicht mehr alleine über die Struktur entscheiden können. Außerdem unterliegen solche DTDs anderen Anforderungen, da die Instanzen oftmals nur von Programmen, nicht von Menschen, gelesen und geschrieben werden.

Sitemap

13.1 Auswahl einer Mehrzweck-DTD