Eine DTD brauchen Sie immer dann, wenn Sie XML-Daten wünschen, die nicht nur 
wohlgeformt, sondern auch gültig sind. Denn "gültig" bedeutet: validierbar gegen eine DTD.
Es ist nicht zwingend notwendig, dass eine XML-Datei "gültig" ist und eine zugehörige DTD besitzt. Das Kriterium der Gültigkeit ist lediglich die "hohe Schule" von XML und der optimale Zustand. In vielen Praxisfällen ist es gar nicht nötig, eine DTD zu haben, z.B. weil man nur ein ordentliches Datenformat benötigt, das aber von keinem Parser interpretiert wird, der auf die Gültigkeit gegen eine DTD testet. Wenn Sie also z.B. einfach Daten in XML-gerechter Form abspeichern wollen und diese mit einem 
CGI-Script verarbeiten, das den XML-Code mit eigenen Befehlen in HTML-Code für den Browser übersetzt, dann brauchen Sie eigentlich keine DTD und können die Dokumenttyp-Deklaration weglassen.
Dennoch ist das Erstellen einer DTD wo immer die Zeit es zulässt sinnvoll. Denn die DTD ist - selbst wenn die Daten im Verarbeitungsprozess nicht auf Gültigkeit getestet werden - in jedem Fall eine Dokumentation des gewünschten Sollzustands der Daten. Vor allem, wenn Datenbestände über einen längeren Zeitraum aufbewahrt und von verschiedenen Personen weiterverarbeitet oder weitergepflegt werden, ist eine DTD eine wichtige normative Grundlage für die Korrektheit und Einheitlichkeit der Daten.
Auch im Hinblick auf die mehrfache Verarbeitung von Daten ist eine DTD wertvoll ("mehrgleisiges Publizieren aus ein und derselben Datenquelle"). Denn nur wenn sichergestellt ist, dass bei der Datenerfassung alle definierten Regeln eingehalten werden, können Programme diese Daten ohne Verlust verarbeiten.
  |
Generell ist es immer von Vorteil, sich an bereits vorhandene Standards zu halten. XML erlaubt zwar das Anlegen eigener DTDs, aber dabei besteht auch die Gefahr, dass das Rad immer wieder neu erfunden wird. Bevor Sie die Entscheidung treffen, eine größere, eigene DTD neu zu entwickeln, sollten Sie sich einen Überblick verschaffen, welche öffentlich zugänglichen DTDs bereits existieren. Eine Übersicht bekannter, vom W3-Konsortium entwickelter XML-Sprachen finden Sie im Abschnitt Wichtige XML-Standardsprachen.
Aber auch wenn Sie eigene DTDs entwickeln, müssen Sie nicht für jede Anwendung eine völlig neue DTD mit allem Drumherum entwickeln. Das DTD-Konzept von XML sieht nämlich die Möglichkeit vor, DTDs modular zu verwenden. Das bedeutet, Sie können sich DTDs für bestimmte Zwecke schreiben und diese dann in andere DTDs einbinden. So ist es möglich, "schlanke" DTDs zu schreiben, die aber dennoch sehr komplexe Daten-Designs enthalten, weil sie sich aus anderen, elementareren DTDs zusammensetzen. Innerhalb eines Unternehmens ist es beispielsweise sinnvoll, sich über solch modulare DTDs Gedanken zu machen. Die Überlegungen, die man dabei anzustellen hat, gleichen denjenigen, die beim Entwurf großer, relationaler Datenbanken anfallen. Es geht dabei also letztlich um die Normalisierung von Daten.
Im Abschnitt Modulare DTDs mit Hilfe von Entities wird das Prinzip beschrieben, wie Sie DTDs in andere DTDs einbinden.
Bei öffentlich bekannten DTDs besteht ein Vorteil darin, dass meist auch schon verarbeitende Software dafür existiert, z.B. Übersetzer-Scripts in HTML, PostScript oder MIF. XML-Sprachen wie SVG etwa werden mittlerweile schon von bekannten Grafikprogrammen verarbeitet. Mit dem Entwickeln einer DTD ist es eben meistens nicht getan - in der Regel benötigt man mehr Software als einen reinen Parser, der die XML-Daten nur überprüft, aber sonst nichts weiter damit tut. Zumindest benötigen Sie in der Regel Stylesheets oder Scripts zur Darstellung von XML-Daten. Der damit verbundene Aufwand kann sich bei umfangreicheren DTDs schnell in der Größenordnung bewegen, in der das Entwickeln einer individuellen Software-Lösung liegt.
| |
Interne DTDs sind nur bei kleinen Projekten zu empfehlen, deren Daten sich nur in dieser einen Datei befinden. Für größere Projekte, bei denen sich mehrere oder etliche Datendateien auf eine gemeinsame DTD beziehen, sollten Sie auf jeden Fall eine externe DTD erstellen.
| |
So wie manche Leute flache und andere Leute tief verschachtelte Verzeichnisstrukturen im Dateisystem bevorzugen, gibt es Verfechter, die DTD und Daten trennen, und andere, die sie zusammen sehen möchten. Gründe lassen sich sicherlich für beide Ansichten finden.
Wichtig ist jedoch die Überlegung, ob auf eine DTD nur vom eigenen Rechner bzw. von lokalen Netzlaufwerken aus zugegriffen wird, oder ob Anwender diese DTD etwa über eine HTTP-Adresse in ihren XML-Daten angeben sollen. In letzterem Fall muss die DTD innerhalb eines Verzeichnisbaums abgelegt werden, die der Webserver als "document root" verwendet. In separate Dateien abgelegte DTDs haben die Dateiendung .dtd.
| |
Beim Entwurf einer DTD müssen Sie jede Menge Namen vergeben - für Elemente, für Attribute und Entities. Abgesehen davon, dass alle vergebenen Namen den Regeln für Namen genügen müssen, ist es angebracht, sich im Vorfeld über ein Namenskonzept Gedanken zu machen. Denn selbst wenn den Anwendern, die mit einer DTD arbeiten sollen, zum Bearbeiten ihrer Daten eine WYSIWYG-Umgebung zur Verfügung steht, so werden sie doch mit den Namen der verfügbaren Elemente und Attribute konfrontiert.
Bei DTDs, die international verwendet werden sollen, ist es normalerweise am besten, nur englische Bezeichnungen zu vergeben, also etwa chapter statt Kapitel oder description statt Beschreibung.
Manchmal gibt es auch Gründe, Autoren-, Abteilungs- oder Firmennamen in die Namensgebung mit einfließen zu lassen, z.B. marketing-statement oder developer-statement.
Bei sehr umfangreichen Datenbeständen kann auch die Länge der Namen eine Rolle spielen. So beträgt der Unterschied zwischen der Notation von <personalausweisnummer>...</personalausweisnummer> und <pnr>...</pnr> 36 Byte, was sich bei 1.000.000 Datensätzen entsprechend multipliziert. Längere Namen haben gegenüber Abkürzungen auf jeden Fall den Vorteil der besseren Lesbarkeit. Abkürzungen sollten stets dokumentiert werden, z.B. innerhalb der DTD in Form von Kommentaren.
Die Namensgebung sollte einem einheitlichen Konzept folgen. Es ist z.B. kein guter Stil, in einigen Elementen Groß-/Kleinschreibung anzuwenden, in anderen dagegen nicht, also z.B. Abteilung, aber raumnummer. Da XML zwischen Groß- und Kleinschreibung unterscheidet, sollte die Namensgebung sich für eine Variante durchgängig entscheiden.
| |
Der Entwurf einer DTD ist - obwohl es sich nicht um "Programmierung" im prozeduralen Sinne handelt - durchaus mit Software-Entwicklung vergleichbar. Bei Software-Projekten, die über einfache kleine Arbeitsscripts hinausgehen, ist es wenig sinnvoll, einfach draufloszuprogrammieren und hinterher festzustellen, dass man zu wenig bedacht und zu wenig auf Erweiterungsmöglichkeiten geachtet hat. Ähnlich ist es beim Entwurf eines Daten-Designs. DTDs werden normalerweise als Regelwerk für eine Klasse von Dokumenten entworfen. Die DTD muss daher flexibel genug sein, um alle aktuellen und absehbaren Anforderungen dieser Dokumentenklasse zu erfüllen.
Der erste Schritt sollte darin bestehen, vorhandenes Datenmaterial, das künftig in XML-Form gespeichert werden soll, zu sichten und zu analysieren. Wie sind die typischen Datenstrukturen aufgebaut? Gibt es beispielsweise in einer Serie von Handbüchern eine immer wiederkehrende und unumstößliche Kapitelreihenfolge? Was ist uneinheitlich und lässt sich vereinheitlichen? Gibt es beispielsweise Handbücher, in denen 5 Überschriftenebenen verwendet werden, und andere, in denen nur 3 verwendet werden? Welche festen Anhaltspunkte gibt es? Gibt es beispielsweise Handbuchabschnitte mit festem Aufbau, z.B. einleitende Funktionsbeschreibung, dann Prozedurbeschreibung, dann Hinweise? Eine Analyse vorhandener Daten liefert den Input zum Daten-Design.
Wenn die vorhandenen Daten ausgewertet sind, sollte man sich auch Gedanken darüber machen, in welcher Weise sich diese Daten später einmal ändern oder erweitern können. Ist es bei einem Handbuchtyp etwa möglich, dass dieser bislang nur Geräte beschreibt, in Zukunft aber auch für die Beschreibung von Software dienen soll? Welche Konsequenzen hätte dies für das Daten-Design? Welche Datenelemente müssten in so einem Fall noch mit berücksichtigt werden? Niemand kann zwar die Zukunft komplett vorhersehen, aber eine DTD sollte durchaus alle denkbare Eventualitäten berücksichtigen. Denn wenn erst einmal massenhaft Daten vorliegen, die auf einer DTD basieren, kann es problematisch werden, die DTD umzustrukturieren.
Bei der Software-Entwicklung hat es sich eingebürgert, im Vorfeld der Kodierung die Funktionsweise der geplanten Software auf verschiedene Weise zu beschreiben. Dafür gibt es Verfahren wie Funktionsbeschreibungen, Flussdiagramme usw. Es gibt Grob- und Feinkonzepte. Für den Entwurf von DTDs haben sich im Laufe der Zeit ähnliche Vorgehensweisen entwickelt. Die Entwicklung einer DTD beinhaltet dabei unter anderem folgende Phasen:
Bei größeren DTDs oder DTD-Verbundsystemen ist es durchaus sinnvoll, die Pläne der Datenstrukturierung in einfacher und unorthodoxer Form zu visualisieren. Hierarchische Abhängigkeiten zwischen geplanten Datenelementen lassen sich z.B. in Form eines numerierten "Inhaltsverzeichnisses" abbilden, relationale Beziehungen zwischen Daten beispielsweise durch Pfeile.
Als maßgeblich für das Entwickeln von DTDs gelten heute die Publikationen von Eve Maler und Jeanne El Andaloussi (suchen Sie gegebenenfalls in einer Suchmaschine oder bei einem Buch-Service wie 
Amazon nach diesen Namen!).
|
| |
 |
Bearbeitungsregeln für DTDs
|
 |
Regeln beim Editieren von XML und Dateinamenkonventionen
|
 SELFHTML/Navigationshilfen XML/DTDs Dokumenttyp-Definitionen (DTDs) |
|
© 2005 Impressum
