Typfragen

Wie bereits erwähnt, könnt Ihr in einem XML-Dokument beliebige Tags und Attribute verwenden oder auch nicht verwenden, solange Eurer Dokument wohlgeformt bleibt. In vielen Fällen jedoch wollt Ihr bestimmte Regeln vorgeben, zum Beispiel

• Innerhalb jedes 'book'-Tags muß genau ein 'price'-Tag stehen
• Innerhalb eines 'price'-Tags darf nur ein Zahlenwert stehen und es dürfen keine weiteren Tags verschachtelt sein.

Solche Dinge werden in einer Document Type Definition, kurz DTD festgelegt. Eine DTD listet alle Elemente, Attribute und Entities, die in Eurem XML-Dokument vorkommen dürfen, und den Kontext, in dem sie benutzt werden. Eure XML-Dokumente müssen nicht alles enthalten, was in der DTD definiert ist, aber alles, was sie enthalten, muß in der DTD definiert sein. Wenn ein XML-Dokument eine DTD besitzt und dieser nicht widerspricht, ist das Dokument gültig (englisch 'valid').

Ähnlich wie bei CSS und JavaScript, kann die DTD eines XML-Dokuments im Dokument selbst stehen, oder sie wird als externe Datei eingebunden. Letzteres geschieht durch die Angabe des DOCTYPE

<!DOCTYPE book SYSTEM "comics.dtd">

Nach dem Schlüsselwort DOCTYPE folgt das Wurzelelement, das verwendet werden soll (in diesem Fall 'book', anschließend das Schlüsselwort SYSTEM, danach der Pfad zur DTD. In unserem Fall liegt 'comics.dtd' im gleichen Verzeichnis, Ihr könnt aber auch eine absolute URL angeben. Wenn wir unser Beispieldokument dieser DTD unterwerfen wollen, sähe das so aus

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<!DOCTYPE book SYSTEM "comics.dtd">

<book>
  <name>Der coole Comic</name>
  <number>1234-5</number>

  <prize currency="euro">5,99</prize>
</product>

Mit XML definierte Sprachen wie XHTML, MathML, SVG oder RDF werden Euch in Form eben einer solchen DTD zur Verfügung gestellt, gegen die Ihr Eure Dokumente validieren (auf Gültigkeit prüfen) könnt. In den meisten Fällen liegen diese DTDs auf Servern irgendwo im Internet, und Ihr müßtet den genauen Pfad in die DOCTYPE-Angabe schreiben. Aber die kennt Ihr nicht immer, und außerdem soll die Validierung möglichst auch offline ohne Kontakt zum Server funktionieren. Das könnt Ihr mit Hilfe von sogenannten öffentlichen IDs erreichen. Damit könnt Ihr die gewünschte DTD angeben, auch ohne ihre exakte URL zu kennen. Wo die «richtige» DTD tatsächlich liegt, weiß (hoffentlich) Eurer Validator-Programm.

<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN"
  "http://my.netscape.com/publish/formats/rss-0.91.dtd">

Diese öffentliche ID verweist auf die RSS-DTD (Rich Site Summary), die Netscape standardisiert hat. Wie Ihr seht, wird das Schlüsselwort SYSTEM durch PUBLIC ersetzt, und anstelle der exakten URL wird ein Identifikationsstring angegeben. Wie der genau aussehen muß, sollte in der Dokumentation der gewünschten DTD stehen. In unserem Beispiel ist zusätzlich die exakte URL (auf dem Netscape-Server) ebenfalls angegeben. Falls der Validator mit dem Identifikationsstring doch nichts anzufangen weiß oder die passende DTD lokal nicht vorliegt, wird versucht, sie von der angegebenen URL zu holen. Für Eure selbstgeschriebenen DTDs braucht Ihr keine öffentlichen IDs; hier könnt Ihr ja selbst dafür sorgen, daß die *.dtd-Datei an der angegebenen URL zu finden ist.

Der Begriff des Validators ist bereits gefallen. Das ist nichts anderes als ein Programm, daß ein XML-Dokument auf Gültigkeit prüft. Dazu gibt es verschiedene Möglichkeiten: Zum einen stellen einige Organisationen auf ihrer Webseite Online-Validatoren zur Verfügung. Dort könnt Ihr Euer XML-Dokument in ein Formular kopieren und validieren lassen. Solche Online-Validatoren setzen häufig öffentliche IDs voraus

• Validator des W3C (speziell für HTML/XHTML)
• Validator von w3schools.com
• Validator der Brown University, Providence

Außerdem gibt es einige Editoren (speziell für XML oder allgemeine Texteditoren), die XML-Dokumente validieren können

• Für den Editor JEdit gibt es ein XML-Plugin, das Ihr einfach über den Plugin-Manager von JEdit installieren könnt. Da JEdit ein Java-Programm ist, benötigt Ihr eine Java2-Laufzeitumgebung auf Eurem Rechner.
• Ebenfalls ein Java-Programm ist der XML-Editor XMLMind (früher bekannt als XEE).
• Für die Windows-Benutzer unter Euch gibt es von Microsoft ein kleines (recht spartanisches) XML-Notepad. Das Notepad nutzt den XML-Parser des Internet Explorers, der also ebenfalls installiert sein muß.

Einige Editoren stellen die Validität Eures Dokuments auf andere Art sicher: Sie erlauben (mittels Drop-Down-Menu) nur das Einfügen solcher Elemente, die die DTD an dieser Stelle gestattet. Solch ein Editor ist beispielsweise Xerlin (früher als Merlot bekannt, ebenfalls ein Java-Programm).

Daneben gibt es eine Vielzahl von mehr oder weniger spezialisierten XML-Entwicklungsumgebungen und anderen Werkzeugen, die aber meist kommerziell und nicht unbedingt billig sind. Von einigen dieser Programme gibt es jedoch zeitbeschränkte Demo-Versionen, so daß Ihr bei Interesse auch solche Programme einmal ausprobieren könnt.

Um eigene DTDs zu schreiben, müßt Ihr natürlich die passende Syntax kennen. In einer DTD wird angegeben, welchen Inhalt die einzelnen Elemente haben dürfen. Das geht nach dem Schema

<!ELEMENT name inhalt>

Um festzulegen, daß in einem book-Element nur genau ein 'name'-Element stehen darf, schreibt Ihr also

<!ELEMENT book name>

Wenn in Eurem Element mehrere Elemente enthalten sein sollen, könnt Ihr diese inneren Elemente einfach aufzählen

<!ELEMENT book (name, number, prize)>

Mit dieser Festlegung muß jedes book-Element genau ein name-Element, ein number-Element und ein prize-Element enthalten, in genau dieser Reihenfolge. Sogenannte Quantifier erlauben es Euch festzulegen, wie oft ein inneres Element vorkommen darf oder muß. Dabei steht

• '?' für keinmal oder genau einmal
• '+' für einmal oder mehrmals
• '*' für beliebig oft (keinmal, einmal oder mehrmals)

Wenn Ihr beispielsweise mehrere prize-Elemente (in verschiedenen Währungen) erlauben wollt, kann das so aussehen

<!ELEMENT book (name, number, prize+)>

Ein leeres Element definiert Ihr mit dem Schlüsselwort EMPTY

<!ELEMENT br EMPTY>

Wenn Ihr verschiedene Möglichkeiten offenlassen wollt, könnt Ihr mit dem Operator | arbeiten

<!ELEMENT autoren (zeichner* | texter*)>

Ein autoren-Element kann also entweder eine beliebige Anzahl an zeichner-Elementen oder eine beliebige Anzahl an texter-Elementen enthalten. Nicht ohne Grund erinnert der Operator an den ||-Operator aus verschiedenen Programmiersprachen. Allerdings funktioniert diese Definition noch nicht so, wie wir uns das vorstellen: Sie akzeptiert auch kein zeichner-Element und kein texter-Element in 'autoren', also ein leeres autoren-Element. Besser ist

<!ELEMENT autoren ((zeichner+, texter*) | (texter+, zeichner*))>

Diese Definition erlaubt entweder mindestens ein zeichner-Element und beliebig viele texter-Elemente oder mindestens ein texter-Element und beliebig viele zeichner-Elemente. Daran könnt Ihr auch sehen, daß Ihr in einer Inhaltsdefinition mehr oder weniger beliebig klammern und verschachteln könnt. Auch die Quantifier könnt Ihr auf Klammern anwenden

<!ELEMENT sammlung (serie, heftnummer)+>

'sammlung' kann also eine oder mehrere Folgen, bestehend aus einem serie-Element und einem heftnummer-Element, aufnehmen. Nachdem Ihr die Folge von Elementen und Kindselementen durchdekliniert habt, kommt Ihr natürlich irgendwann zu Elementen, die einfach nur Text enthalten sollen. Dazu gibt es das Schlüsselwort #PCDATA

<!ELEMENT zeichner #PCDATA>

Eine Einschränkung muß ich noch erwähnen: Wenn ihr sogenannte gemischte Elemente deklarieren wollt, die sowohl #PCDATA als auch Kindselemente enthalten, könnt Ihr nur eine Folge mit #PCDATA und den Kindselementen deklarieren

<!ELEMENT gemischt (#PCDATA|kind1|kind2|kind3)*>

#PCDATA muß an erster Stelle stehen, und weitere Verschachtelungen sind nicht möglich.

Nach den Elementen müssen wir noch die Attribute deklarieren. Dazu dient das Schlüsselwort !ATTLIST

<!ATTLIST elementname attribut typ
  attribut2 typ
  attribut3 typ>

Ein Beispiel für eine Attribut-Deklaration ist

<!ATTLIST prize currency CDATA #REQUIRED
  contains_taxes (yes|no)>

Jedes prize-Element muß also ein currency-Attribut besitzen (das «muß» legt das Schlüsselwort #REQUIRED fest) und kann ein contains_taxes-Attribut haben. Dabei kann das currency-Attribut beliebige in einem XML-Dokument erlaubte Zeichen enthalten, das contains_taxes-Attribut einen der Werte «yes» oder «no». Es gibt noch einige weitere Typen für Attribute, auf die ich hier aber nicht weiter eingehen werde, da Ihr fast alles mit CDATA und Aufzählungen (wie bei contains_taxes) realisieren könnt.

Zum Schluß des Themas DTD noch ein paar Worte zu Entities: XML hat nur fünf Entities vordefiniert

• &lt; erzeugt ein <
• &gt; erzeugt ein >
• &amp; erzeugt ein &
• &quot; erzeugt ein "
• &apos; erzeugt ein '

Weitere Entities könnt Ihr selbst definieren. Um beispielsweise nicht jedesmal «ABComics & Co. Ltd.» tippen zu müssen, definiert Ihr in Eurer DTD

<!ENTITY abc "ABComics &Co. Ltd.">

Diese Entity könnt Ihr dann in Eurem XML-Dokument als &abc; verwenden. Der Text, der anstelle der Entitiy eingesetzt wird (hier «ABComics & Co. Ltd.»), muß wohlgeformt sein (darf also auch Tags enthalten). Er darf seinerseits Entities enthalten, solange sich kein «Kreisschluß» ergibt.

Hier kommt auch wieder das bereits erwähnte standalone-Attribut in der XML-Deklaration ins Spiel: Wenn Ihr keine DTD zuweist, bekommt standalone den Wert «yes». Aber auch mit einer DTD kann standalone «yes» sein, wenn die DTD rein intern ist (komplett in der XML-Datei definiert ist), oder die DTD das XML-Dokument nicht verändert (beispielsweise durch die Ersetzung einer Entity). In allen anderen Fällen ist standalone «no».