XML/DTD/Elemente und Verschachtelungsregeln
Ein Element ist das, was in einer XML-basierten Auszeichnungssprache durch eine Notation wie z. B. <geburtsdatum>...</geburtsdatum> dargestellt wird. In einer DTD können Sie den zugehörigen Elementtyp definieren, also etwa den Elementtyp geburtsdatum. Dabei bestimmen Sie den Namen des Elements und geben an, welchen Inhalt das Element haben kann.
Elemente können auch verschachtelt sein, und es sind Regeln möglich, wie oft und an welchen Stellen ein Element vorkommen kann. So kann in HTML etwa das Element <tr>...</tr> nur innerhalb von <table>...</table> vorkommen. Zwischen <table> und </table> dürfen Sie darüber hinaus auch keinen Text notieren, sondern müssen die Tabellenstruktur beachten, die innere Elemente wie <tr>...</tr> fordert. Solche Regeln bestimmen Sie beim Definieren der Elementtypen Ihrer DTD.
Inhaltsverzeichnis
- 1 Schema zur Definition von Elementtypen
- 2 Elementtypen mit Zeicheninhalt definieren
- 3 Elementtypen mit Elementinhalt definieren
- 4 Beliebig viele Wiederholungen eines Elementtyps definieren
- 5 Alternative und optionale Elementtypen für Elementinhalt definieren
- 6 Elemente mit gemischtem Inhalt definieren
- 7 Elemente mit beliebigem Inhalt definieren
- 8 Leere Elemente ohne Inhalt definieren
- 9 Elementgruppen zusammenfassen
- 10 Zusammenhängendes Beispiel: ein Buch
Schema zur Definition von Elementtypen
Elementtypen werden innerhalb einer DTD nach folgendem Schema notiert:
<!ELEMENT Name (Inhalt)>
Die Definition eines Elements beginnt mit einer öffnenden spitzen Klammer <. Dahinter folgt unmittelbar anschließend ein Ausrufezeichen ! und dahinter, in Großbuchstaben, das Schlüsselwort ELEMENT. Anschließend folgt ein Name für das Element. Den Namen können Sie frei wählen. Er muss jedoch den Regeln für Namen in XML genügen. Hinter dem Namen notieren Sie Angaben zum Inhalt des Elementtyps. Diese Angaben können recht komplex sein und regeln, woraus ein Element bestehen kann. Abgeschlossen wird die Elementtyp-Definition mit einer schließenden spitzen Klammer >. Die einzelnen Teile der Elementtyp-Definition werden durch ein oder mehrere Leerzeichen voneinander getrennt.
Eine solche Elementtyp-Definition können Sie an irgendeiner Stelle innerhalb der DTD definieren – vor oder nach anderen Definitionen wie <!ATTLIST...> (Attribute), <!ENTITY...> (Entities) oder <!NOTATION...> (Notationen).
Elementtypen mit Zeicheninhalt definieren
Zeicheninhalt bedeutet, dass ein Element als Inhalt beliebigen und beliebig viel Text enthalten kann, aber keine weiteren Elemente. Zeicheninhalt ist eine beliebige und beliebig lange Zeichenfolge, also Text, Zahlen, und Sonderzeichen.
<!ELEMENT durchwahlnummer (#PCDATA)>
Im Beispiel wird ein Elementtyp definiert, der in der Anwendung als Element <durchwahlnummer>...</durchwahlnummer> notiert werden kann. Es gilt das Schema zur Definition von Elementtypen. Den Zeicheninhalt kennzeichnen Sie durch den Schlüsselbezeichner #PCDATA (Abkürzung für parsed character data, zu deutsch analysierte Zeichendaten). Das Gatterzeichen ist erforderlich, PCDATA muss groß geschrieben sein, und das Ganze muss in runde Klammern eingeschlossen sein.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE durchwahlnummer SYSTEM "durchwahlnummer.dtd">
<durchwahlnummer>123456</durchwahlnummer>
Der Elementtyp durchwahlnummer erlaubt Zeichendaten, eine Zeichenfolge wie 123456 ist also ein korrekter Inhalt.
durchwahlnummer ist in diesem extrem einfachen Beispiel zugleich das Dokument-Element.- PCDATA bedeutet zwar so viel wie "beliebig viel Text", aber es bedeutet auch so viel wie "keine anderen, inneren Elemente". Eine Anwendung wie
<durchwahlnummer><fett>123456</fett></durchwahlnummer>ist nach der Definition des Elementsdurchwahlnummeralso unzulässig. Für solche Fälle müssen Sie Elementtypen mit Elementinhalt oder Elementtypen mit gemischtem Inhalt definieren.
Das P in PCDATA bedeutet, dass der Inhalt vom XML-Parser durchaus analysiert wird. Für die Praxis bedeutet dies, dass im Inhalt eines so definierten Elements die Regeln für Zeichen und Zeichenkodierungen zu beachten sind.
In der Version 1.0 unterscheidet XML nicht zwischen verschiedenen Datentypen etwa für numerische oder alphanumerische Daten. Der Datentyp PCDATA entspricht dem Datentyp für alphanumerische Zeichenketten (Strings) in Programmiersprachen – Datentypen für Zahlen, Datumsformate oder dergleichen gibt es nicht. Dies wird von Entwicklern bereits als großer Nachteil empfunden, und künftige Versionen von XML werden vermutlich neben PCDATA mehrere Datentypen anbieten.
Elementtypen mit Elementinhalt definieren
Im Gegensatz zu einem Elementtyp mit Zeicheninhalt ist ein Elementtyp mit Elementinhalt ein solcher, der andere, innere Elementtypen enthält. Er darf jedoch selber keine Zeichendaten enthalten, sondern nur aus anderen Elementen bestehen.
<!ELEMENT telefonnummer (vorwahlnummer, durchwahlnummer)>
<!ELEMENT vorwahlnummer (#PCDATA)>
<!ELEMENT durchwahlnummer (#PCDATA)>
Im Beispiel werden drei Elementtypen definiert. Die erste der drei Definitionen ist dabei ein Elementtyp mit Elementinhalt. Eine solche Definition hat den gleichen Aufbau wie die Definition eines Elementtyps mit Zeicheninhalt. Es gilt das Schema zur Definition von Elementtypen. Der Unterschied besteht darin, dass in den runden Klammern, in denen der Inhalt des Elementtyps definiert wird, die Namen anderer Elementtypen notiert werden, und zwar durch Kommata getrennt.
Im obigen ersten Beispiel wird für den Elementtyp telefonnummer eine feste Elementfolge definiert, bestehend aus den Elementtypen vorwahlnummer und durchwahlnummer. Der Elementtyp telefonnummer darf also nach obiger Definition genau einmal die Elemente vorwahlnummer und durchwahlnummer enthalten, und zwar in dieser Reihenfolge.
Zugleich ist das Element telefonnummer im Beispiel das Dokument-Element, also das äußerste Element der Daten.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE telefonnummer SYSTEM "telefonnummer.dtd">
<telefonnummer>
<vorwahlnummer>069</vorwahlnummer>
<durchwahlnummer>974791003</durchwahlnummer>
</telefonnummer>
Die Elementtypen telefonnummer, vorwahlnummer und durchwahlnummer sind so verschachtelt, wie es in der DTD definiert wurde. Die Elementtypen vorwahlnummer und durchwahlnummern enthalten nichts anderes als Zeichendaten und damit einen korrekten Inhalt.
Beliebig viele Wiederholungen eines Elementtyps definieren
Wenn Sie nichts anderes angeben, darf ein Elementtyp nur einmal vorkommen. Damit das Element eines Elementtyps mehrfach notiert werden kann, müssen Sie dies in der DTD kenntlich machen.
<!ELEMENT kochrezept (zutatenliste, anweisungsfolge)>
<!ELEMENT zutatenliste (zutat)+>
<!ELEMENT zutat (#PCDATA)>
<!ELEMENT anweisungsfolge (anweisung)*>
<!ELEMENT anweisung (#PCDATA)>
Das Beispiel einer einfachen DTD für ein Kochrezept. Für alle Definitionen im Beispiel gilt das Schema zur Definition von Elementtypen. Definiert wird zunächst der Elementtyp kochrezept für das Dokument-Element. Dieser Elementtyp hat Elementinhalt. Der Inhalt besteht aus den beiden Elementtypen zutatenliste und anweisungsfolge. Diese beiden Elementtypen werden definiert. Beide bestehen wiederum aus Elementinhalt.
Dabei kann zutatenliste einen oder mehrere Elementtypen zutat enthalten. Der Grund ist das Pluszeichen + in der Definition hinter der Angabe zum Inhalt. Durch das Pluszeichen geben Sie an, dass der Inhalt, im Beispiel der Elementtyp zutat, innerhalb von zutatenliste mindestens einmal vorkommen muss, ansonsten aber beliebig oft vorkommen kann. Für das Kochrezeptebeispiel ist ein solches Konstrukt durchaus sinnvoll, denn ein Rezept sollte wenigstens aus einer Zutat bestehen.
Der Elementtyp anweisungsfolge kann ebenfalls mehrere Elementtypen anweisung enthalten, kann jedoch auch leer bleiben. Der Grund ist in diesem Fall das Sternzeichen * in der Definition hinter der Angabe zum Inhalt. Durch das Sternzeichen geben Sie an, dass der Inhalt, im Beispiel der Elementtyp anweisung, innerhalb von anweisungsfolge kein mal, einmal oder beliebig viele male vorkommen kann. Für das Kochrezeptebeispiel bedeutet dies, dass es auch Kochrezepte mit Zutaten, aber ohne Anweisungen geben kann.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE kochrezept SYSTEM "kochrezept.dtd">
<kochrezept>
<zutatenliste>
<zutat>300 g Kartoffeln geschält</zutat>
<zutat>2 lg Lauchstangen</zutat>
<zutat>1 Zwiebel</zutat>
<zutat>1 tb Butter</zutat>
<zutat>600 ml Wasser</zutat>
</zutatenliste>
<anweisungsfolge>
<anweisung>Kartoffeln in kleine Würfel schneiden.</anweisung>
<anweisung>Lauch putzen und in dünne Ringe schneiden.</anweisung>
<anweisung>Zwiebel schälen, fein würfeln und in der Butter glasig dünsten.</anweisung>
<anweisung>Kartoffeln, Lauch und Wasser hinzufügen und 18 bis 20 Minuten garen.</anweisung>
</anweisungsfolge>
</kochrezept>
Die Elementtypen sind so verschachtelt, wie es in der DTD definiert wurde. Die Elementtypen zutat und anweisung kommen innerhalb von zutatenliste bzw. anweisungsfolge mehrfach vor, was nach der Definition erlaubt ist. Innerhalb von zutat und anweisung kommt in allen Fällen nur Zeicheninhalt vor, so wie es für diese Elementtypen mit dem Schlüsselbezeichner #PCDATA definiert wurde.
anweisung enthalten würde, was ja nach der Definition mit dem Sternzeichen durchaus erlaubt wäre, so müssten Sie in einer gültigen Anwendung trotzdem notieren:
<anweisungsfolge></anweisungsfolge>
kochrezept im obigen Beispiel festgelegt wurde, dass dieses Element aus den beiden Elementtypen zutatenliste und anweisungsfolge bestehen muss, und dass diese beiden Elementtypen vorkommen müssen, nämlich genau einmal.Alternative und optionale Elementtypen für Elementinhalt definieren
Wenn Sie Elementtypen mit Elementinhalt definieren, kann es vorkommen, dass die starre Folge von Elementen, die Sie für den Elementtyp vorsehen, in der Praxis nicht immer sinnvoll ist. Bei einer Postadresse etwa könnte man alternativ zwischen der Angabe einer Straßen-/Hausnummernangabe und einer Postfachangabe unterscheiden, und bei der Angabe zur Anredeform einer Person ist ein typisches Beispiel für eine optionale Angabe, also etwas, das man bei einigen Adressen mit angeben möchte, bei anderen dagegen nicht.
<!ELEMENT adressen (adresse)*>
<!ELEMENT adresse (anrede?, name, (postfach | wohnanschrift), plzort)>
<!ELEMENT anrede (#PCDATA)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT postfach (#PCDATA)>
<!ELEMENT wohnanschrift (#PCDATA)>
<!ELEMENT plzort (#PCDATA)>
Das Beispiel zeigt eine einfache DTD zu einer Adressverwaltung. Für alle Definitionen im Beispiel gilt das Schema zur Definition von Elementtypen. Definiert wird ein Elementtyp namens adressen für das Dokument-Element. Dieser kann beliebig viele Wiederholungen des Elements adresse enthalten. Der Elementtyp adresse definiert ein Element mit Elementinhalt. Der Inhalt besteht aus verschiedenen Elementtypen für die einzelnen Daten einer Adresse. Diese Elementtypen werden als einfache Elementtypen mit Zeicheninhalt definiert.
Die Anrede wird im Beispiel als optional definiert. Verantwortlich dafür ist das Fragezeichen ? in der Definition hinter der Angabe zum Inhalt beim Namen des Elementtyps. Die einfache Notation von anrede würde die Verwendung des Elementtyps als zwingend erforderlich definieren, während die Notation von anrede? die Verwendung als optional kennzeichnet.
Ferner wird im Beispiel definiert, dass als Anschrift entweder eine Angabe zum Postfach oder zur Wohnanschrift gemacht werden kann. Dazu werden die alternativen Elementtypen nochmals geklammert. Innerhalb der Klammer werden die alternativen Elementtypen notiert, und zwar getrennt durch Senkrechtstriche |.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE adressen SYSTEM "adressen.dtd">
<adressen>
<adresse>
<name>Wurmstädter Anlagenbank</name>
<postfach>7001</postfach>
<plzort>00234 Wurmstadt</plzort>
</adresse>
<adresse>
<anrede>Herr</anrede>
<name>Willi Wacholder</name>
<wohnanschrift>Holzwurmstr. 30</wohnanschrift>
<plzort>00234 Wurmstadt</plzort>
</adresse>
</adressen>
Im Beispiel werden zwei Adressen notiert. Die erste Adresse ist die einer Bank, daher entfällt bei dieser Adresse die Anrede, die nur für Personen benötigt wird. Da der Elementtyp anrede? als optional definiert wurde, ist das Weglassen erlaubt. Im Beispiel der Bank ist die Anschrift ein Postfach. Da an dieser Stelle laut Definition entweder der Elementtyp postfach oder der Elementtyp wohnanschrift vorkommen kann, ist die Anwendung korrekt. Bei der zweiten Adresse handelt es sich um die einer Person. In diesem Fall ist die Anrede notiert, und anstelle eines Postfachs eine Straßen-/Hausnummernangabe im Alternativ-Element wohnanschrift.
Elemente mit gemischtem Inhalt definieren
Wenn Sie XML-Anwendungen definieren möchten, in denen Elemente nicht so starr gruppiert sein müssen, sondern in relativ freier Folge notiert werden können – so wie beispielsweise in HTML – dann müssen Sie Elemente mit gemischtem Inhalt definieren. In HTML ist <body>...</body> so ein typisches Element. Innerhalb dieses Elements können Sie die meisten anderen HTML-Elemente in relativ freier Folge und unter Berücksichtigung einiger weniger Verschachtelungsregeln notieren. Für Anwendungen, die generell weniger in Richtung Datenbank und stattdessen mehr in Richtung Freitext gehen, benötigen Sie solche gemischten Inhalte.
<!ELEMENT text (#PCDATA | drohend | lachend | fragend | zynisch)*>
<!ELEMENT drohend (#PCDATA)>
<!ELEMENT lachend (#PCDATA | augenzwinkernd)*>
<!ELEMENT fragend (#PCDATA)>
<!ELEMENT augenzwinkernd (#PCDATA)>
<!ELEMENT zynisch (#PCDATA)>
Das Beispiel stellt eine DTD für Text dar, in dem Emotionen als solche kenntlich gemacht werden. Für alle Definitionen im Beispiel gilt das Schema zur Definition von Elementtypen. Definiert wird ein Elementtyp namens text für das Dokument-Element mit gemischtem Inhalt. Gemischten Inhalt bestimmen Sie, indem Sie zum Inhalt des Elements, also innerhalb der Klammern, den Schlüsselbezeichner #PCDATA für Zeicheninhalt und außerdem eine Reihe erlaubter Elementtypen für weiteren Elementinhalt notieren. Die Einträge müssen mit dem Senkrechtstrich | für alternativ notierte Elementtypen getrennt werden. Außerdem muss der gesamte Inhalt am Ende wie im Beispiel das Sternzeichen * für beliebig viele Elemente erhalten. Dadurch darf jedes dieser Elemente beliebig oft in dem Bereich notiert werden kann, in dem es erlaubt ist. Gemischter Inhalt ist also eine Kombination aller hier zuvor behandelten Definitionsmöglichkeiten.
Im Beispiel werden die weiteren, bei text notierten Elementtypen ebenfalls definiert. Mit Ausnahme des Elementtyps lachend wird für alle Elementtypen nichts weiter als reiner Zeicheninhalt (#PCDATA) erlaubt. Der Elementtyp lachend entspricht dagegen wieder dem Muster für gemischten Inhalt. Neben reinem Zeicheninhalt wird in diesem Elementtyp noch der weitere Elementtyp augenzwinkernd zugelassen.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE text SYSTEM "text.dtd">
<text>
Manchmal sagt einem das Gewissen: <drohend>du musst mehr über Frauen und
Männer nachdenken.</drohend>
Dann fragt man sich zwar manchmal, <fragend>warum es darüber wohl
so viel nachzudenken gibt,</fragend>
aber manchmal folgt man auch brav und denkt nach.
Sagt die Frau zum Mann: <lachend>Mann o Mann, <augenzwinkernd>du bist
dein Geld wert!</augenzwinkernd></lachend>
Antwortet der Mann: <zynisch>Ja, weil ich den Einkaufswagen schiebe
und sich eine Mark darin befindet!</zynisch>
Daraufhin die Frau: <lachend>Du hast es erfasst!</lachend>
</text>
Das Anwendungsbeispiel enthält das Dokument-Element <text>..</text> und innerhalb davon typischen gemischten Inhalt. Es kommt normaler Text vor (Zeichendaten), aber auch weitere Elemente. Das lachend-Element kommt insgesamt zweimal vor. Genauso gut könnte auch z. B. das drohend-Element zwei- oder mehrfach innerhalb eines text-Elements vorkommen. Dies ist aufgrund der Verwendung des Sternzeichens * bei der Definition aller inneren Elementtypen erlaubt. Das Element augenzwinkernd kommt wie laut DTD erlaubt innerhalb von lachend vor – außerhalb davon dürfte es jedoch nicht vorkommen.
Elemente mit beliebigem Inhalt definieren
Elemente mit beliebigem Inhalt sind eine Steigerungsform von Elementen mit gemischtem Inhalt. Es handelt sich dabei gewissermaßen um Joker- oder Wildcard-Elemente, deren Inhalt in keiner Weise festgelegt ist. Alle übrigen in der DTD definierten Elementtypen können in einem Element mit beliebigem Inhalt vorkommen.
<!ELEMENT anytext ANY>
<!ELEMENT english (#PCDATA)>
<!ELEMENT italiano (#PCDATA)>
Für alle Definitionen im Beispiel gilt das Schema zur Definition von Elementtypen. Durch das Schlüsselwort ANY (großgeschrieben) anstelle der konkreten Definition eines Elementinhalts geben Sie an, dass dieses Element (im Beispiel das Dokument-Element) beliebigen Zeicheninhalt und Elementinhalt enthalten kann. Im Beispiel sind zwei andere Elementtypen definiert, die ebenfalls vorkommen dürfen.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE anytext SYSTEM "anytext.dtd">
<anytext>
Das ist etwas Text, der in Englisch lautet:
<english>this is some text</english> und in italienisch:
<italiano>ciò è un certo testo</italiano>
</anytext>
Im Beispiel wird das Dokument-Element <anytext>...</anytext> definiert. Darin können Zeichendaten und beliebige andere Elemente vorkommen, zu denen es in der DTD einen Elementtyp gibt. Das Beispiel zeigt eine einfache Mischung.
Leere Elemente ohne Inhalt definieren
Leere Elemente sind solche ohne Inhalt. Im klassischen HTML sind etwa <br> oder <img> solche Elemente. Dort redet man auch von Standalone-Elementen. In der Philosophie von XML ist eigentlich für jedes Element ein Inhalt vorgesehen. Wenn Sie Elementtypen definieren wollen, die keinen Inhalt haben, müssen Sie dies gesondert angeben. Auch die Notation der Elemente in der Anwendung weist darauf hin, dass es sich um einen Sonderfall handelt.
<!ELEMENT textzeilen (#PCDATA | neuezeile)*>
<!ELEMENT neuezeile EMPTY>
Im Beispiel werden zwei Elementtypen definiert: ein Elementtyp textzeilen für das Dokument-Element mit gemischtem Inhalt, und ein Elementtyp neuezeile, der innerhalb des Elementtyps textzeilen beliebig vorkommen darf. Für beide Definitionen gilt das Schema zur Definition von Elementtypen.
Der Elementtyp neuezeile ist dabei ein leerer Elementtyp. Kenntlich gemacht wird dies durch das Schlüsselwort EMPTY (zu deutsch: leer) an der Stelle, wo der Inhalt des Elementtyps definiert wird.
Beispiel einer gültigen Anwendung:
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE textzeilen SYSTEM "textzeilen.dtd">
<textzeilen>
Das ist Text, aber wo beginnt die<neuezeile />
neue Zeile?
</textzeilen>
Im Beispiel wird das Element ohne Inhalt entsprechend der Regeln für leere Elemente notiert. Für eine Umsetzung der Bedeutung "neuezeile" kann natürlich erst eine Style-Sprache wie CSS oder XSL sorgen.
Elementgruppen zusammenfassen
Beim Entwurf größerer DTDs mit vielen Elementtypen werden Sie schnell feststellen, dass es viele Wiederholungen speziell bei Elementtypinhalten gibt. Viele Elementtypen bilden oft logisch gesehen eine zusammengehörige Gruppe, die geschlossen als Elementinhalt mehrerer anderer, übergeordneter Elementtypen vorkommt. Für solche Fälle bietet die DTD-Syntax die Möglichkeit an, Elementtypen zu solchen logischen Gruppen zusammenzufassen. Eine logische Gruppe von Elementtypen bezeichnet man als Parameter Entity. Der Einsatz von Parameter Entities erhöht in komplexen DTDs die Lesbarkeit und die Änderungsfreundlichkeit. Beschrieben wird diese Möglichkeit im Abschnitt Parameter Entities für DTD-Bausteine.
Zusammenhängendes Beispiel: ein Buch
Um komplexe Abhängigkeiten und Regeln bei der Definition von Elementtypen abzubilden, ist es wichtig, die richtigen Überlegungen anzustellen und sich ein Modell der geplanten Elementstruktur zu machen.
Viele Datenstrukturen weisen eine starke logische Hierarchie auf. Gut sichtbar wird das am Beispiel eines Buches. Ein Buch besteht typischerweise aus Kapiteln, Verzeichnissen und speziellen Seiten wie Impressum, Titel usw. Jedes Kapitel besteht aus einer Kapitelüberschrift und Abschnitten. Jeder Abschnitt besteht aus einer Abschnittsüberschrift und dem Abschnittsinhalt. Ein Abschnittsinhalt kann Dinge wie normale Fließtextabsätze, Aufzählungen, Grafikreferenzen usw. enthalten. Jeder Fließtextabsatz, jeder Aufzählungspunkt kann Textteile mit speziellen Formatierungen enthalten, etwa für Fettschrift, Kursivschrift usw. enthalten.
Bei solchen Datenstrukturen ist es am sinnvollsten, wenn man beim Entwurf der Elementtypen und ihrer Abhängigkeiten vom Allgemeinen (das Buch) hin zum Speziellen (das fett markierte Wort in einem Absatz) denkt. XML unterstützt diese Art stark hierarchischer Datenstrukturen besonders gut, da sich ein Dokument nach der Philosophie von XML als Baumstruktur abbilden lässt. Die Umsetzung einer stark hierarchischen Elementstruktur ist denn auch in einer XML-DTD vergleichsweise einfach und gut nachvollziehbar.
<!ENTITY % text "hervorgehoben | hinweisend | auffordernd | zeilenumbruch">
<!ELEMENT buch (titel,impressum,inhaltsverzeichnis,(kapitel)+,stichwortverzeichnis)>
<!ELEMENT titel (haupttitel,untertitel)>
<!ELEMENT haupttitel (#PCDATA)>
<!ELEMENT untertitel (#PCDATA)>
<!ELEMENT impressum (cip,copyright,verlag)>
<!ELEMENT cip (#PCDATA | %text;)*>
<!ELEMENT copyright (#PCDATA | %text;)*>
<!ELEMENT verlag (#PCDATA | %text;)*>
<!ELEMENT inhaltsverzeichnis (ivz_ueberschrift,(ivz_kapiteleintrag | ivz_abschnittseintrag)*)>
<!ELEMENT ivz_ueberschrift (#PCDATA)>
<!ELEMENT ivz_kapiteleintrag (#PCDATA)>
<!ELEMENT ivz_abschnittseintrag (#PCDATA)>
<!ELEMENT kapitel (kap_ueberschrift,(abschnitt)+)>
<!ELEMENT kap_ueberschrift (#PCDATA)>
<!ELEMENT abschnitt (ab_ueberschrift,(fliesstext | aufzaehlung | grafik)+)>
<!ELEMENT ab_ueberschrift (#PCDATA)>
<!ELEMENT fliesstext (#PCDATA | %text;)*>
<!ELEMENT aufzaehlung (aufzaehlungspunkt)+>
<!ELEMENT aufzaehlungspunkt (#PCDATA | %text;)*>
<!ELEMENT grafik (grafikdatei)>
<!ELEMENT grafikdatei (#PCDATA)>
<!ELEMENT stichwortverzeichnis (svz_ueberschrift,(svz_eintrag)*)>
<!ELEMENT svz_ueberschrift (#PCDATA)>
<!ELEMENT svz_eintrag (#PCDATA)>
<!ELEMENT hervorgehoben (#PCDATA)>
<!ELEMENT hinweisend (#PCDATA)>
<!ELEMENT auffordernd (#PCDATA)>
<!ELEMENT zeilenumbruch EMPTY>
Beispiel einer gültigen Anwendung
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE buch SYSTEM "buch.dtd">
<?xml:stylesheet type="text/css" href="buch.css" ?>
<buch>
<titel>
<haupttitel>Ich bin der Valentin</haupttitel>
<untertitel>Wie mein Leben wurde was es geworden ist</untertitel>
</titel>
<impressum>
<cip>Deutsche Bibliothek - CIP-Einheitsaufnahme:<zeilenumbruch />
Titeldatensatz erhältlich bei der Deutschen Bibliothek</cip>
<copyright>©2000 alle Rechte beim Verlag</copyright>
<verlag>Eigenverlag, Hinter den Sieben Bergen</verlag>
</impressum>
<inhaltsverzeichnis>
<ivz_ueberschrift>Inhaltsverzeichnis</ivz_ueberschrift>
<ivz_kapiteleintrag>Meine frühen Jahre</ivz_kapiteleintrag>
<ivz_abschnittseintrag>Kindheit</ivz_abschnittseintrag>
<ivz_abschnittseintrag>Jugend</ivz_abschnittseintrag>
<ivz_kapiteleintrag>Wie ich zum Manne wurde</ivz_kapiteleintrag>
<ivz_abschnittseintrag>Die erste Liebe</ivz_abschnittseintrag>
</inhaltsverzeichnis>
<kapitel>
<kap_ueberschrift>Meine frühen Jahre</kap_ueberschrift>
<abschnitt>
<ab_ueberschrift>Kindheit</ab_ueberschrift>
<fliesstext>
Meine Kindheit bestand aus zwei Lebensabschnitten:
</fliesstext>
<aufzaehlung>
<aufzaehlungspunkt>- dem Säuglingsalter</aufzaehlungspunkt>
<aufzaehlungspunkt>- dem Kindesalter</aufzaehlungspunkt>
</aufzaehlung>
</abschnitt>
<abschnitt>
<ab_ueberschrift>Jugend</ab_ueberschrift>
<fliesstext>
Meine Jugend bestand im wesentlichen aus Pickeln.
</fliesstext>
</abschnitt>
</kapitel>
<kapitel>
<kap_ueberschrift>Wie ich zum Manne wurde</kap_ueberschrift>
<abschnitt>
<ab_ueberschrift>Die erste Liebe</ab_ueberschrift>
<fliesstext>
Sie <hervorgehoben>kam</hervorgehoben>, <hervorgehoben>geschah</hervorgehoben>, und <hervorgehoben>verging</hervorgehoben> wieder.
</fliesstext>
<grafik>
<grafikdatei>ersteliebe.tif</grafikdatei>
</grafik>
</abschnitt>
</kapitel>
<stichwortverzeichnis>
<svz_ueberschrift>Stichwortverzeichnis</svz_ueberschrift>
<svz_eintrag>Jugend</svz_eintrag>
<svz_eintrag>Kindheit</svz_eintrag>
<svz_eintrag>Liebe</svz_eintrag>
<svz_eintrag>Pickel</svz_eintrag>
<svz_eintrag>Säugling</svz_eintrag>
</stichwortverzeichnis>
</buch>
Das Beispiel kann natürlich nur grob ein komplettes Buch beschreiben – wenn Sie tatsächlich versuchen, eine komplette Buchstruktur mit Hilfe von XML zu beschreiben, werden Sie sicher noch viel mehr Details benötigen. Das Beispiel will jedoch zeigen, wie eine solche Beschreibung im Prinzip aussehen kann.
In dem Beispiel wird zunächst eine Parameter Entity definiert. Darin werden vier Elementtypen hervorgehoben, hinweisend, auffordernd und zeilenumbruch zusammengefasst, die innerhalb von verschiedenen Textabsätzen vorkommen können.
Der Rest der DTD besteht in der Definition der gewünschten Elementtypen. Die Reihenfolge spielt eigentlich keine Rolle, doch das Beispiel hält eine gewisse Logik ein und versucht, vom Allgemeinen hin zum Speziellen fortzuschreiten. Das Element, in dem das gesamte Buch steht, wird mit dem Namen buch definiert. Das Element hat Elementinhalt. Dabei können die Elementtypen titel, impressum, inhaltsverzeichnis und stichwortverzeichnis genau einmal vorkommen, und zwar in der notierten Reihenfolge. Lediglich der Elementtyp kapitel, in der Reihenfolge zwischen inhaltsverzeichnis und stichwortverzeichnis stehend, muss mindestens einmal und kann beliebig oft vorkommen. Damit ist die Grundstruktur des Buches festgelegt.
Die Bereiche titel und impressum enthalten als Elementinhalt entsprechende Elementtypen. Bei den untergeordneten Elementtypen von impressum wird erstmals die definierte Parameter Entity angewendet. Die entsprechenden Elementtypen hervorgehoben, hinweisend, auffordernd und zeilenumbruch können innerhalb von cip, copyright und verlag beliebig oft vorkommen. Die übrigen Bereiche des Buches untergliedern sich nach ähnlichem Schema in einzelne Elementtypen.
