Zwei DTD-Beispiele

(Auszug aus "XML in a Nutshell" von Elliotte Rusty Harold & W. Scott Means)

Einige der besten Techniken für den DTD-Entwurf werden nur dann offensichtlich, wenn Sie sich längere Dokumente anschauen. Auf dieser Seite werden wir DTDs entwickeln, die die zwei unterschiedlichen Dokumentformate zum Beschreiben von Personen abdecken, die im Code-Beispiel Ein XML-Dokument, das eine Person mit Attributen beschreibt und im Code-Beispiel Ein narratives XML-Dokument, das Attribute verwendet auf der Seite "Attribute" präsentiert wurden.

DTDs für datensatzähnliche Dokumente

DTDs für datensatzähnliche Dokumente sind recht einfach aufgebaut. Sie machen starken Gebrauch von Sequenzen, weniger starken von Auswahlen und fast keinen Gebrauch von gemischtem Inhalt. Das nächste Beispiel zeigt eine solche DTD. Da dieses Beispiel klein ist und es leichter zu verstehen ist, wenn sich sowohl das Dokument als auch die DTD auf der gleichen Seite befinden, haben wir daraus eine interne DTD gemacht, die in das Dokument eingebunden ist. Ohne Probleme ließe sie sich aber auch in eine eigene Datei schreiben.

Code-Beispiel: Eine DTD zur Beschreibung von Personen

Die DTD hier ist vollständig in der internen DTD-Teilmenge enthalten. Zuerst sagt die person-ELEMENT-Deklaration aus, dass jede person ein oder mehrere Kindelemente name und kein oder mehrere Kindelemente beruf besitzen muss, und zwar in dieser Reihenfolge. Diese Regel kalkuliert die Möglichkeit mit ein, dass jemand seinen Namen ändert oder Alias-Namen benutzt. Sie geht davon aus, dass jede Person wenigstens einen Namen hat, aber nicht unbedingt einen Beruf.

Diese Deklaration verlangt außerdem, dass alle name-Elemente allen beruf-Elementen vorangehen. An dieser Stelle ist die DTD nicht so flexibel, wie sie es idealerweise sein sollte. Es gibt keinen bestimmten Grund, weshalb die Namen zuerst kommen müssen. Wenn wir allerdings eine zufälligere Reihenfolge zulassen würden, wäre es schwer zu bestimmen, dass es wenigstens ein name-Element geben muss. Eine der Schwächen von DTDs besteht darin, dass sie manchmal die Festlegung einer Reihenfolge erfordern, wenn man eigentlich nur eine bestimmte Anzahl von Elementen bestimmen will.

Sowohl die name- als auch die beruf-Elemente sind leer, ihre Deklarationen sind deshalb sehr einfach. Die Attribut-Deklarationen sind ein wenig komplizierter. In allen drei Fällen ist die Form des Attributs offen, alle drei Attribute sind deshalb vom Typ CDATA. Außerdem müssen alle drei Attribute vorhanden sein. Beachten Sie jedoch den Einsatz von Kommentaren, um eine Lösung für Grenzfälle – wie etwa Berühmtheiten ohne Nachnamen – vorzuschlagen. Kommentare sind ein wichtiges Mittel, um DTDs zu erklären, die ansonsten sinnlos erscheinen würden.

DTDs für narrative (erzählende) Dokumente

»Narrative« DTDs sind meist viel freier und greifen viel stärker auf gemischte Inhalte zurück als DTDs, die eher datenbankartige Dokumente beschreiben. Folglich werden sie gern von unten nach oben geschrieben, das heißt, es wird mit den kleinsten Elementen begonnen und bis zu den größten fortgefahren. Oft benutzen sie auch Parameter-Entities, um ähnliche Inhaltsspezifizierungen und Attributlisten zusammenzufassen.

Das folgende Beispiel ist eine einzelne DTD für Biographien wie die aus dem Code-Beispiel Ein narratives XML-Dokument, das Attribute verwendet. Beachten Sie, dass nicht alles, was in der DTD deklariert wird, auch tatsächlich im genannten Code-Beispiel vorhanden ist. Das ist bei erzählenden Dokumenten oft der Fall. Zum Beispiel enthalten nicht alle Webseiten ungeordnete Listen, trotzdem muss die XHTML-DTD das Element ul deklarieren, falls XHTML-Dokumente es einsetzen wollen. Sie sehen außerdem, dass einige Attribute im genannten Code-Beispiel mit festen Vorgabewerten versehen wurden.

Code-Beispiel: Eine DTD für Biographien

Das Wurzelelement biographie hat eine klassische Deklaration gemischten Inhalts. Da es hier mehrere Elemente gibt, die in ziemlich unvorhergesehener Weise andere Elemente enthalten können, gruppieren wir all diese möglichen Top-Level-Elemente (Elemente, die als unmittelbares Kindelement des Wurzelelements auftreten) in einer einzigen top_level-Entity-Referenz. Wir können sie dann in einfacher Weise untereinander zu potenziellen Kindelementen machen. Durch diesen Schritt wird außerdem in Zukunft das Hinzufügen neuer Elemente stark vereinfacht. Das ist wichtig, da dieses kleine Beispiel mit großer Wahrscheinlichkeit nicht ausreichend ist, um alle möglichen Biographien abzudecken.