SELFHTML/Navigationshilfen  XML/DTDs  Dokumenttyp-Definitionen (DTDs)
	Allgemeines zu DTDs
	Wann ist eine DTD n�tig?  Eigene oder vorhandene DTD verwenden?  Datei-interne oder DTD in separater Datei verwenden?  Ablageort f�r DTDs in separaten Dateien  Namenskonzept f�r eine DTD  Datenanalyse als Vorbereitung zum Entwurf einer DTD

Wann ist eine DTD n�tig?

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.

Eigene oder vorhandene DTD verwenden?

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.

Datei-interne oder DTD in separater Datei verwenden?

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.

Ablageort f�r DTDs in separaten Dateien

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.

Namenskonzept f�r eine 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.

Datenanalyse als Vorbereitung zum Entwurf einer DTD

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:

• Ziele f�r das Projekt, f�r das die DTD entwickelt werden soll, sollten ausformuliert werden. So z.B. Validierbarkeit von Dokumenten, M�glichkeit des Mehrfachpublizierens, bessere Konvertierf�higkeit usw.
• Anforderungen an die Dokumente, die auf der zu entwickelnden DTD basieren sollen, m�ssen genau ausgearbeitet werden. Dabei helfen folgende Fragestellungen:
  Welche grundlegenen Informationseinheiten m�ssen diese Dokumente enthalten?
  In welche logische Gruppen lassen sich diese Informationseinheiten einteilen?
  Mit welchen bereits vorhandenen Datenmodellen l�sst sich das neu zu erstellende Modell vergleichen?
• Anforderungen an die DTD m�ssen genau ausgearbeitet werden. Dabei helfen folgende Fragestellungen:
  Welche Datenstrukturen werden ben�tigt?
  Welche Daten sollen obligatorisch sein und welche fakultativ?
  Welche der Strukturen m�ssen unver�nderlich und in fester Reihenfolge auftreten?
  Welche Daten geh�ren in den Inhalt von Elementen, und welche zu den Eigenschaften (Attributen)?
  Bei solchen Fragen des Daten-Designs kann auf die Erfahrungen und das Wissen von Software-Entwicklern, aber auch auf das der Dokument-Anwender zur�ckgegriffen werden.
• Feinkonzept der DTD. Dazu geh�rt:
  das Ausw�hlen der f�r die DTD ben�tigten Elemente,
  das Ausarbeiten der Element- und Attributmodelle f�r die Dokumenthierarchie und der verschiedenen Elementebenen,
  die Validierung des Modells.
• Komplettierung der Entwicklung und die Implementierung der DTD. Dazu geh�rt auch die Entscheidung, ob und wie die DTD modularisiert (auf mehrere DTDs verteilt) werden soll, sowie die Frage danach, wie die DTD nach der Einf�hrung gewartet und weiterentwickelt werden kann. Eine ausreichende Dokumentation der DTD (vergleichbar etwa einer W3-Empfehlung zu einer Sprache wie HTML) geh�rt ebenfalls zu den Aufgaben.
• Test der DTD. Dazu geh�rt das �berpr�fen der DTD mit Hilfe konkreter, realistischer Dokumente und damit das �berpr�fen der gesetzten Ziele.

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)

© 2007  Impressum