UNIVERSITÄT GIESSEN
Institut für Informatik
Dr. Stefan Brass

Kompaktkurs XML, Kapitel 3: ``Document Type Definitions''

Ziel

• Document Type Defintions (DTDs) legen zusätzliche Einschränkungen für XML-Dokumente fest, die über die reine Wohlgeformtheit hinaus gehen.

  Aus der Spezifikation, Abschnitt 2.8: ``The XML document type declaration contains or points to markup declarations that provide a grammar for a class of documents. This grammar is known as a document type definition, or DTD.'' [http://www.w3.org/TR/REC-xml#sec-prolog-dtd]

• Zum Beispiel definieren DTDs,
  1. welche Element-Typen (Tags) es gibt,
  2. welche Elemente im Inhalt welcher anderen Elemente vorkommen können (und ob sie wiederholbar oder optional sind, welche Reihenfolge eingehalten werden muß),
  3. welche Elemente Text-Daten enthalten können,
  4. welche Attribute ein Element-Typ hat und
  5. was mögliche Werte für ein Attribut sind.
• Im Prinzip ist eine DTD einfach eine kontextfreie Grammatik für die Daten.

  Man kann eine gegebene DTD direkt in eine kontextfreie Grammatik (CFG) übersetzen. Dabei führt man für jeden Element-Typ ein entsprechendes Nichtterminal-Symbol ein. Die Regel, daß Attribute in beliebiger Reihenfolge angegeben werden können, aber keines mehrfach, ist in der CFG allerdings nur umständlich auszudrücken (Außerdem können ID/IDREF-Attribute (s.u.) nicht kontextfrei dargestellt werden.). Umgekehrt kann man eine kontextfreie Grammatik auch in eine DTD übersetzen (wieder mit der Entsprechung Nichtterminalsymbol - Elementtyp), aber man behält dann mit den Start- und End-Tags Markierungen zurück, die den ganzen Ableitungsbaum im Ergebniswort codieren. Man könnte also vielleicht sagen, daß man eine beliebige kontextfreie ``abstrakte Syntax'' als DTD darstellen kann, aber die konkrete Syntax dann von XML vorgeschrieben wird.

• Eine DTD kann im Dokument selbst definiert werden (``internal subset''), in einer (oder mehreren) anderen Dateien definiert werden (``external subset''), oder kann aus internem und externem Anteil bestehen.

  Dies wird unten noch näher erläutert (siehe unter ``Dokument-Typ Deklaration'')

• Beispiel (Datei booklist.dtd) [http://www.informatik.uni-giessen.de/staff/brass/xml00/booklist.dtd]:

  <!-- Document Type Definition für Literaturlisten -->
  <!ELEMENT BOOKLIST (BOOK)*>
  <!ELEMENT BOOK (AUTHOR+, TITLE, PUBL?, NOTE?)>
  <!ATTLIST BOOK ISBN CDATA #REQUIRED
                    PAGES CDATA #IMPLIED>
  <!ELEMENT AUTHOR EMPTY>
  <!ATTLIST AUTHOR FIRST CDATA #IMPLIED
                    MI CDATA #IMPLIED
                    LAST CDATA #REQUIRED>
  <!ELEMENT TITLE (#PCDATA)>
  <!ELEMENT PUBL (#PCDATA)>
  <!ATTLIST PUBL YEAR CDATA #IMPLIED
                    MO CDATA #IMPLIED>
  <!ELEMENT NOTE (#PCDATA)>
  

• Folgende Datei [http://www.informatik.uni-giessen.de/staff/brass/xml00/books2.xml] basiert auf dieser DTD und ist ``valid'':

  <?xml version="1.0"?>
  <!-- Kommentar: Einige Bücher zur XML-Definition -->
  <!DOCTYPE BOOKLIST SYSTEM "booklist.dtd">
  <?xml-stylesheet type="text/xsl" href="books.xsl"?>
  <BOOKLIST>
           <BOOK ISBN="0-13-014714-1" PAGES="1074">
                    <AUTHOR FIRST="Paul" LAST="Prescod"/>
                    <AUTHOR FIRST="Charles" MI="F." LAST="Goldfarb"/>
                    <TITLE>The XML Handbook - 2nd Edition</TITLE>
                    <PUBL YEAR="1999" MO="11">Prentice Hall</PUBL>
                    <NOTE>Contains CD.</TITLE>
           </BOOK>
           <BOOK ISBN="1-56592-709-5" PAGES="107">
                    <AUTHOR FIRST="Robert" LAST="Eckstein"/>
                    <TITLE>XML Pocket Reference</TITLE>
                    <PUBL YEAR="1999" MO="10">O'Reilly</PUBL>
           </BOOK>
           <BOOK ISBN="0-13-082676-6" PAGES="368">
                    <AUTHOR FIRST="Bob" LAST="DuCharme"/>
                    <TITLE>XML: The Annotated Specification</TITLE>
                    <PUBL YEAR="1998" MO="12" >Prentice Hall</PUBL>
           </BOOK>
  </BOOKLIST>
  

Element-Deklarationen

• Eine Element-Deklaration besteht aus
  1. der Zeichenfolge ``<!ELEMENT'',
  2. dem Namen des Element-Typs,
  3. einer Spezifikation über das Format des Inhaltes des Elementes (was also zwischen öffnendem und schließendem Tag stehen darf, ``content model'') und
  4. dem Zeichen ``>''.

  Alle Deklarationen in XML beginnen mit ``<!''.

• Für die Inhalts-Spezifikation gibt es vier Möglichkeiten:
  1. kein Inhalt erlaubt,
  2. beliebiger Inhalt,
  3. nur Elemente (mit vorgeschriebener Struktur) (``element content''),
  4. Elemente und Text (mit Angabe welche Elemente zulässig sind) (``mixed content'').

  Natürlich kann ein Element bei der dritten Möglichkeit (``element content'') indirekt Text enthalten, nämlich innerhalb dieser Elemente. Aber die Kind-Knoten in der Baum-Darstellung sollen dann sämtlich Element-Knoten sein, keine Text-Knoten.

• Die Festlegung, daß ein Element leer sein muß, geschieht mit dem Schlüsselwort ``EMPTY'':

  <!ELEMENT AUTHOR EMPTY>
  

  Es wäre übrigens ein Syntaxfehler, Klammern um das Wort ``EMPTY'' zu setzen. In diesem Fall müßten ``AUTHOR''-Elemente jeweils genau ein Element vom Typ ``EMPTY'' enthalten. Man beachte auch, daß wenn man Start- und End-Tag für ein als leer deklariertes Element verwendet, dazwischen nicht einmal ein Leerzeichen stehen darf.

• Ein anderer häufiger Spezialfall ist, daß ein Element nur Text enthalten kann, aber keine weiteren Elemente:

  <!ELEMENT TITLE (#PCDATA)>
  

  Dies zählt formal als ``mixed content'', obwohl es gar nicht gemischt ist (reiner Text). ``#PCDATA'' steht für ``parsed character data''. Im Unterschied zu CDATA (``character data'')-Abschnitten muß der Inhalt hier syntaktisch analysiert werden, um zu prüfen, daß auch wirklich keine Elemente darin vorkommen (und um Entity-Referenzen zu ersetzen). Hier sind übrigens die Klammern nötig, sonst wäre es ein Syntaxfehler. (Ich kenne keine einleuchtende Erklärung, warum die Klammern nötig sind.) Die Markierung ``#'' ist nötig, um es als Schlüsselwort zu kennzeichnen. Läßt man es weg, so würde der Parser statt dessen ein Element vom Typ ``PCDATA'' erwarten.

• Oft enthält ein Element im wesentlichen Text, von dem aber Teile in weitere Tags eingeschlossen sind. Zum Beispiel könnte es sein, daß man definierende Vorkommen von Worten im Text markieren möchte (DEF), sowie auch Namen (NAME). Dann hat man ein echtes ``mixed content model''. In der Baum-Darstellung kann ein solcher Knoten eine Folge von Text- und Element-Knoten als Kinder haben. Zum Beispiel wäre folgender Inhalt möglich:

  <P>Ein Komitee unter Leitung von <NAME>Charles Goldfarb</NAME>
  entwickelte <DEF>SGML</DEF>, die Standard Generalized Markup Language,
  von 1978 bis 1986 zu einem internationalen Standard. </P>
  

  Solcher Inhalt wird in folgender Form definiert:

  <!ELEMENT P (#PCDATA | DEF | NAME)*>
  

  Der senkrechte Strich ``|'' bedeutet ``oder'', der Stern ``*'' bedeutet null oder mehrmalige Wiederholung. Der Inhalt von Elementen des Typs P ist also eine beliebige Folge von Text-Daten, Elementen vom Typ DEF und Elementen vom Typ NAME. Die Elemente müssen nicht unbedingt vorkommen und können aber auch mehrfach vorkommen.

  XML bietet keine Möglichkeit, zu spezifizieren, daß die Elemente vorkommen müssen, nur in bestimmter Reihenfolge vorkommen dürfen, oder nicht mehrfach vorkommen dürfen. (Alles dies wird aber möglich bei ``element content'', wenn man den Text also noch in Elemente einschließen würde.) Die Inhalts-Spezifikation muß übrigens genau so aussehen: Obwohl ``|'' normalerweise kommutativ sein sollte, muß ``#PCDATA'' ganz am Anfang stehen. Für die anderen Element-Typen kommt es dagegen auf die Reihenfolge nicht an, es darf aber kein Element-Typ mehrfach angegeben werden.

  Leerzeichen etc. sind links und rechts vom senkrechten Strich erlaubt, aber nicht notwendig. Sie sind auch links und rechts von der öffnenden Klammer erlaubt, aber nur links von der schließenden Klammer. Zwischen ``)'' und ``*'' darf kein Leerzeichen stehen. Das ist schon ein bißchen merkwürdig. Am einfachsten merktman es sich so, daß Leerzeichen überall erlaubt sind, wo man es erwarten würde, außer vor dem Wiederholungssymbol.

• Beliebiger Inhalt wird mit dem Schlüsselwort ``ANY'' erlaubt:

  <!ELEMENT EXAMPLE ANY>
  

  Es scheint, daß dies äquivalent ist zu

  <!ELEMENT EXAMPLE (#PCDATA|...)*>
  

  Dabei ist ... eine Aufzählung aller deklarierten Element-Typen.

  Auch bei ANY müssen alle im Dokument verwendeten Element-Typen mit ``<!ELEMENT'' deklariert sein, sonst ist das Dokument nicht gültig.

• Man beachte schließlich noch, daß kein Element-Typ mehr als einmal in einer DTD definiert sein darf.

Inhalts-Spezifikation für ``Element Content''

• Wenn ein Element-Typ als Inhalt nur andere Elemente haben kann, aber nicht direkt Text, spricht man von ``Element Content''. Für diesen Fall bietet XML recht mächtige Definitionsmöglichkeiten für die Struktur des Inhalts.
• Man kann Auswahl ``|'' und Sequenz ``,'' verwenden, diese auch (fast) beliebig schachten, und für jede Gruppe definieren, ob sie
  1. optional ist (``?'', null oder einmal),
  2. optional und wiederholbar (``*'', null oder mehrfach), oder
  3. notwendig und wiederholbar (``+'', einmal oder mehrfach).
  4. Gibt man keines der drei Zeichen an, so muß das Element genau einmal vorkommen (notwendig und nicht wiederholbar).
• Zum Beispiel legt folgende Definition fest, daß jedes BOOK-Element genau drei Kinder haben muß, die die Typen AUTHOR, TITLE, und PUBLISHER haben, und in dieser Reihenfolge angegeben sein müssen:

  <!ELEMENT BOOK (AUTHOR, TITLE, PUBLISHER)>
  

• Sequenz hat also die allgemeine Syntax ``(..., ..., ...)''. Sie erzwingt eine Reihenfolge für n, n>=1, Elemente.

  Links und rechts der Kommata sind Leerzeichen erlaubt, aber nicht nötig.

• Für jedes Element der Sequenz (wie auch für die Sequenz als ganzes) kann man Optionalität und Wiederholbarkeit definieren, z.B.:

  <!ELEMENT BOOK (AUTHOR+, TITLE, PUBLISHER?)>
  

  Dies bedeutet, daß es mehr als einen Autoren geben kann (aber mindestens einen geben muß), und daß der Publisher entfallen kann. Es muß genau einen Titel geben, und kann nicht mehr als einen Verlag geben. Die Reihenfolge ist: Erst die Autoren, dann der Titel, und zum Schluß der Verlag (falls vorhanden). Möchte man erlauben, daß es auch gar keine Autoren kann, so muß man das ``+'' durch ein ``*'' ersetzen.

  Zwischen den Namen der Element-Typen und den Zeichen +, *, ? sind keine Leerzeichen erlaubt. Wieder ist die allgemeine Regel die, daß Leerzeichen überall erlaubt sind, wo man es erwarten würde, außer vor dem Wiederholungs-/Optionalitäts-Symbol. Leerzeichen sind natürlich auch nicht nach <, <! oder <? erlaubt (aber schon vor >).

• Man kann auch die ganze Liste wiederholbar machen, z.B.:

  <!ELEMENT AUTHORS (FIRST, LAST)+>
  

  Dies erlaubt mehrere Paare von Vorname und Nachname, z.B.:

  <AUTHORS><FIRST>Udo</FIRST><LAST>Lipeck</LAST>
           <FIRST>Stefan</FIRST><LAST>Brass</LAST></AUTHORS>
  

  Man beachte, daß in dem letzten Beispiel der Leerplatz (neue Zeile, Tabulator) zwischen den Elementen zulässig ist, obwohl die Inhaltsspezifikation reinen ``Element Content'' vorschreibt. Dies vereinfacht die Eingabe und erlaubt, XML Code schöner zu formatieren. Wenn der XML Parser aufgrund der DTD weiß, daß dort eigentlich kein Leerplatz erlaubt ist, muß er den Text zwar immernoch an die Anwendung weitergeben, aber ihr gleichzeitig mitteilen, daß dieser Leerplatz unwesentlich ist.

• Inhalts-Spezifikationen für ``Element Content'' bekommen ihre Mächtigkeit auch dadurch, daß man die Konstrukte schachteln kann. Überall, wo ein Name stehen kann, kann auch selbst wieder eine Auswahl oder Sequenz stehen. Zum Beispiel ist folgendes möglich:

  <!ELEMENT BOOK ((FIRST, LAST)+, TITLE, PUBLISHER?)>
  

  Es müssen dann zunächst Paare von Vornamen und Nachnamen angegeben werden (mindestens einmal), dann ein Titel, und zum Schluß möglicherweise ein Verlag.
• Neben der mit ``,'' markierten Sequenz gibt es auch die mit ``|'' markierte Auswahl. Zum Beispiel bedeutet ``(PUBL|UNI)'',

  <!ELEMENT ADDRESS (POSTAL | EMAIL | PHONE)>
  

  daß jedes ADDRESS-Element genau eines der drei Elemente ``POSTAL'', ``EMAIL'' oder ``PHONE'' enthalten muß.

  ``Genau eines'' bedeutet mindestens eins und maximal eins. Die Auswahl wird selten ganz pur verwendet, sondern normalerweise innerhalb einer Wiederholung oder einer Sequenz.

• Es sind beliebige Schachtelungen von Auswahl und Sequenz möglich, z.B.:

  <!ELEMENT BOOK ((FIRST, LAST)+, TITLE, (PUBLISHER|UNI)?)>
  

  Dies erlaubt anstelle der Angabe eines Verlages auch die Angabe einer Universität (etwa für technische Berichte). Aufgrund des ``?'' kann die Angabe aber auch ganz entfallen.
• Aufgabe: Wie kann man definieren, daß ein Element A die Elemente B und C enthalten muß, aber in beliebiger Reihenfolge (entweder erst B, dann C, oder erst C dann B). In SGML gibt es dafür eine eigene Notation, die aber zur Vereinfachung in XML weggelassen wurde.
• Jede Inhaltsspezifikation für ``Element Content'' muß mindestens ein Paar Klammern enthalten. Selbst wenn jedes Element A das Element B genau einmal enthalten soll, muß man folgendes schreiben:

  <!ELEMENT A (B)>
  

  Diese Situation kommt allerdings nicht besonders häufig vor. Namen außerhalb von Klammern sind nicht möglich, da es dann zur Kollision mit ``EMPTY'' und ``ANY'' kommen kann.

• Wiederholungs-/Optionalitäts-Angaben sind sowohl nach Element-Typen als auch nach der schließenden Klammer einer Auswahl oder Sequenz möglich. Zum Beispiel ist folgendes äquivalent:

  <!ELEMENT A (B*)>
  <!ELEMENT A (B)*>
  

  Dagegen ist folgendes natürlich nicht äquivalent:

  <!ELEMENT A (B*, C*)>
  <!ELEMENT A (B, C)*>
  

• Element-Typ Deklarationen sind in Abschnitt 3.2 der XML Spezifikation behandelt [http://www.w3.org/TR/REC-xml#elemdecls].

``Deterministic Content Models''

• Schließlich fordert XML ``deterministic content models''. Das bedeutet, daß der XML Parser allein durch ansehen des nächsten Elementes in der Eingabe entscheiden kann, welchen Weg er bei einer Auswahl verfolgen muß.
• Zum Beispiel wäre folgendes nicht zulässig:

  <!ELEMENT EXAMPLE ((A, B) | (A, C))>
  

  Wenn der Parser das A liest, muß er sich zwischen den beiden Alternativen entscheiden, ohne zu wissen, ob danach ein B oder ein C folgt.
• Es ist in der Informatik durchaus bekannt, wie man das Problem lösen kann (man kann jeden nichtdeterministischen endlichen Automaten in einen deterministischen endlichen Automaten umwandeln). Aber der XML Standard fordert aus Kompatibilitätsgründen mit existierenden SGML Systemen diese Einschränkung. Es macht die Entwicklung von Parsern etwas einfacher, wenn diese Umwandlung nicht nötig ist.
• Dafür muß der XML Benutzer die Inhaltsspezifikation dann so aufschreiben:

  <!ELEMENT EXAMPLE (A, (B | C))>
  

  Dies beschreibt das gleiche Format für den Inhalt, ist aber ein ``deterministic content model''.
• Das Problem tritt übrigens nicht nur bei Auswahl auf. Auch das folgende Beispiel wäre unzulässig:

  <!ELEMENT EXAMPLE2 ((A, B)*, (A, C))>
  

  Aufgabe: Geben Sie eine äquivalente deterministische Inhalts-Spezifikation an.
• (Mündlich:) Aufbau des endlichen Automaten für eine Inhaltsspezifikation.
• Anhang E der XML Spezifikation beschäftigt sich mit ``Deterministic Content Models'' [http://www.w3.org/TR/REC-xml#determinism].

Definition von Attributen

• Man kann Attribute für einen Elementtyp in der folgenden Form definieren:

  <!ATTLIST AUTHOR FIRST CDATA #IMPLIED
                    MI CDATA #IMPLIED
                    LAST CDATA #REQUIRED>
  

• Die Deklaration von Attributen eines Element-Typs besteht aus
  1. der Zeichenkette ``<!ATTLIST'',
  2. dem Namen des Element-Typs,
  3. ein oder mehreren Attribut-Deklarationen und
  4. dem Zeichen ``>''.

  Tatsächlich läßt die XML Grammatik auch null Attribut-Deklarationen in einer ``<!ATTLIST''-Deklaration zu, aber dann braucht man die ganze Deklaration nicht.

• Jede einzelne Attribut Deklaration besteht aus drei Teilen:
  1. dem Namen des Attributes,
  2. dem Typ des Attributes und
  3. einer Default Deklaration.
• Ein wichtiger Typ von Attributen ist ``CDATA''. Es sind dann beliebige Zeichenketten erlaubt (die aber kein ``<'' enthalten können, und ``&'' nur für Entity-Referenzen). Weitere Typen von Attributen werden unten erläutert.
• Default-Deklarationen haben vier Formen:
  1. #REQUIRED,
  2. #IMPLIED,
  3. ein Default-Wert,
  4. #FIXED mit der Angabe eines konstanten Wertes.
• #REQUIRED bedeutet, daß das Start-Tag für jedes Element dieses Types eine Attributwert-Angabe für dieses Attribut enthalten muß.

  In SGML war das Zeichen ``#'' notwendig, weil ``REQUIRED'' auch ein Default-Wert (s.u.) sein konnte. In XML müssen die Default-Werte dagegen immer in Anführungszeichen eingeschlossen werden, so daß auch ohne ``#'' keine Verwechselung möglich wäre. Aber aus Kompatibilitätsgründen wollte man die Schlüsselwörter nicht ändern.

• #IMPLIED bedeutet, daß die Angabe des Attribut-Wertes optional ist.

  Falls bei einem Element kein Wert angegeben ist, wird der Anwendung mitgeteilt, daß es keinen Wert für das Attribut gibt (es wird also nicht ein Default-Wert angenommen). Es wird dann davon ausgegangen, daß die Anwendung selbst einen Wert für das Attribut berechnen kann (etwa eine fortlaufende Kapitel-Nummer), daher der Name ``Implied''. Dies ist aber nicht erforderlich, und das Schlüsselwort ``#OPTIONAL'' wäre wohl sinnvoller gewesen.

• Wenn in der Attribut-Deklaration ein Default-Wert angegeben ist, so bekommt jedes Element, in dessen Start-Tag nicht explizit ein Wert spezifiziert ist, diesen Default-Wert für das Attribut. Zum Beispiel:

  <!ATTLIST BOOK OWNER CDATA "Library">
  

  Dann ist ``<BOOK>'' äquivalent zu

  <BOOK OWNER="Library">
  

  Man kann aber auch explizit einen anderen Wert angeben:

  <BOOK OWNER="SB">
  

• Die letzte Möglichkeit ist, einen Wert fest vorzuschreiben:

  <!ATTLIST P xml:space CDATA #FIXED "preserve">
  

  Dies bedeutet, daß das Attribut nur den einen Wert haben kann, und dieser auch gleichzeitig Default-Wert ist, also nicht explizit angegeben werden braucht.

  Dies ist nur interessant für ``globale Attribute'', die also mehr als einem Element-Typ zukommen. Für die verschiedenen Element-Typen können dann unterschiedliche Werte deklariert werden. Zum Beispiel die XLink-Spezifikation macht von solchen Attributen Gebrauch, um Element-Typen als Hyperlinks zu kennzeichnen.

• Es ist zulässig, mehr als eine Attribut-Liste für einen Element-Typ zu haben. Man kann sogar mehr als eine Deklaration für das gleiche Attribut haben, in welchem Fall die erste Deklaration ausschlaggebend ist, und alle weiteren Deklarationen ignoriert werden.

  Allerdings wird von beiden Möglichkeiten abgeraten, und XML Parser können eine Option anbieten, in solchen Fällen eine Warnung auszugeben.

• Attribut-Deklarationen werden in Abschnitt 3.3 der Spezifikation behandelt [http://www.w3.org/TR/REC-xml#attdecls].

Daten-Typen für Attribute

• CDATA: Beliebiger String (``character data'').
• Aufzählungen, zum Beispiel ``(yes|no)'': Das Attribut muß einen der angegebenen Werte haben. Die Werte müssen Folgen von Buchstaben, Zifferen, Unterstrich ``_'', Bindestrich ``-'', Punkt ``.'' und Doppelpunkt ``:'' sein. Dies sind die gleichen Zeichen, die in Namen verwendet werden dürfen, aber es gibt keine Beschränkung bezüglich des ersten Zeichens. Zum Beispiel können numerische Werte wie 2000 verwendet werden. Beispiel:

  <!ATTLIST MEAL VEGETARIAN (yes|no) "no"
                    COOKED (rare|medium|well-done) #IMPLIED>
  

  Man beachte, daß in der Aufzählung keine Anführungszeichen erlaubt sind, aber man einen Default-Wert hinterher in Anführungszeichen angeben muß.

• ID: Dies sind eindeutige Namen für das Element. Attribut-Werte müssen die gleichen Einschränkungen wie Namen erfüllen, zusätzlich kann jeder Name im ganzen XML-Dokument aber nur einmal in einem Attribut dieses Typs verwendet werden. Dadurch identifiziert jeder solche Name eindeutig ein Element. Kein Element-Typ kann mehr als ein Attribut dieses Typs haben. Es ist üblich, aber nicht Vorschrift, Attribute dieses Typs auch ``ID'' zu nennen:

  <!ATTLIST BOOK ID ID #IMPLIED>
  

  Es macht keinen Sinn, für Attribute dieses Typs einen Default-Wert anzugeben, und die Spezifikation schreibt auch vor, daß sie nur zusammen mit #REQUIRED und #IMPLIED verwendet werden können.

  Kein Element-Typ kann mehr als ein Attribut dieses Typs haben. Dies ist ein Problem für XHTML, weil in HTML jedes Element ein Attribut ``ID'' hat (zur Identifikation in Javascript-Programmen), aber ``A''-Elemente noch zusätzlich das Attribute ``NAME'' haben, das ebenfalls eine eindeutig sein muß.

  Man beachte, daß Nummern nicht zulässig als Wert von ID-Attributen sind. Das ist schade, weil in Datenbanken häufig Kundennummern, Angestellten-Nummern, etc. verwendet werden. Man kann sich natürlich behelfen, indem man einen Buchstaben voranstellt, z.B. ``K1001'' für Kunden 1001. Das kann auch nützlich sein, weil IDs in XML global eindeutig sein müssen. Es kann z.B. nicht ein Element vom Typ ``KUNDE'' und ein Element vom Typ ``WARE'' mit der gleichen ID geben. In Datenbanken beziehen sich Schlüssel dagegen immer nur auf eine Relation.

• IDREF: Attribute dieses Typs verweisen auf andere Elemente. Attribut-Werte müssen wieder zulässige Namen sein, und sie müssen außerdem im XML Dokument als Wert eines Attributes des Typs ID vorkommen.

  Natürlich kann es mehrere Verweise auf das gleiche Element geben. Der Verweis kann im Dokument auch textuell vor dem Element stehen, auf das verwiesen wird. Die ``ID'' muß also an dieser Stelle noch nicht definiert sein, vorwärts-Referenzen sind möglich.

  Es ist in XML DTDs nicht möglich, vorzuschreiben, auf welchen Typ von Elementen verwiesen wird. Natürlich kann man ein Attribut vom Typ ``IDREF'' so verwenden, daß z.B. immer nur auf Produkte verwiesen wird. Aber dies kann in der DTD nicht vorgeschrieben werden, und ein XML Parser würde keine Fehlermeldung ausgeben, wenn so ein Verweis einmal auf einen Kunden zeigt.

• IDREFS: Attribute dieses Typs verweisen auf eine Menge anderer Elemente. Attribut-Werte müssen eine durch Leerplatz (Leerzeichen etc.) getrennte Liste von Namen sein.

  Wie vorher muß jeder einzelne Name im XML Dokument als Wert eines Attributes vom Typ ID auftreten.

• NMTOKEN: Attribut-Werte müssen Folgen von Buchstaben, Ziffern, und den vier Zeichen ``_'', ``-'', ``.'' und ``:'' sein.

  Es gibt wieder keine Beschränkung bezüglich des ersten Zeichens. Zahlen wie 3.14 sind also zulässig, aber zum Beispiel auch ``.:X-_''. DTDs erlauben nicht, vorzuschreiben, daß nur numerische Werte für ein Attribut zulässig sind (siehe aber den Vorschlag für XML Schemas).

• NMTOKENS: Dies ist entsprechend eine durch Leerzeichen etc. getrennte Liste von NMTOKEN-Werten. Zum Beispiel:

  <BOX COLOR="0 50 100">
  

• Daneben gibt es noch die Typen ENTITY, ENTITIES, und Aufzählungen von Notationen. Diese werden im nächsten Kapitel erläutert.
• Abschnitt 3.3.1 [http://www.w3.org/TR/REC-xml#sec-attribute-types] behandelt Datentypen für Attribute.

Beispiel für ID/IDREF

• Wenn man noch weitere Informationen über Autoren erfassen will, z.B. eine EMail-Adresse oder Homepage (soweit bekannt), dann wären diese Informationen redundant dargestellt, wenn einige Autoren mehrere Bücher geschrieben haben.

  Im Datenbank-Entwurf, besonders bei der Normalisierung, versucht man solche Redundanzen zu vermeiden. Redundanzen führen häufig zu Inkonsistenzen und doppelter Arbeit.

• Eine Lösung ist, die Information über Autoren getrennt von der Information über Bücher zu erfassen und in den Buch-Elementen auf die Autor-Elemente zu verweisen: [http://www.informatik.uni-giessen.de/staff/brass/xml00/books3.xml]:

  <?xml version="1.0"?>
  <!DOCTYPE BOOKLIST SYSTEM "books3.dtd">
  <BOOKLIST>
           <AUTHOR ID="PP" FIRST="Paul" LAST="Prescod"/>
           <AUTHOR ID="CG" FIRST="Charles" MI="F." LAST="Goldfarb"/>
           <AUTHOR ID="RE" FIRST="Robert" LAST="Eckstein"/>
           <AUTHOR ID="BC" FIRST="Bob" LAST="DuCharme"/>
           <BOOK AUTHORS="PP CG" ISBN="0-13-014714-1" PAGES="1074">
                    <TITLE>The XML Handbook - 2nd Edition</TITLE>
                    <PUBL YEAR="1999" MO="11">Prentice Hall</PUBL>
                    <NOTE>Contains CD.</TITLE>
           </BOOK>
           <BOOK AUTHORS="RE" ISBN="1-56592-709-5" PAGES="107">
                    <TITLE>XML Pocket Reference</TITLE>
                    <PUBL YEAR="1999" MO="10">O'Reilly</PUBL>
           </BOOK>
           <BOOK AUTHORS="BC" ISBN="0-13-082676-6" PAGES="368">
                    <TITLE>XML: The Annotated Specification</TITLE>
                    <PUBL YEAR="1998" MO="12" >Prentice Hall</PUBL>
           </BOOK>
  </BOOKLIST>
  

• Die DTD dazu sieht so aus [http://www.informatik.uni-giessen.de/staff/brass/xml00/books3.dtd]:

  <!ELEMENT BOOKLIST (AUTHOR | BOOK)*>
  <!ELEMENT AUTHOR EMPTY>
  <!ATTLIST AUTHOR ID ID #REQUIRED
                    FIRST CDATA #IMPLIED
                    MI CDATA #IMPLIED
                    LAST CDATA #REQUIRED>
  <!ELEMENT BOOK (TITLE, PUBL?, NOTE?)>
  <!ATTLIST BOOK AUTHORS IDREFS #IMPLIED
                    ISBN CDATA #REQUIRED
                    PAGES CDATA #IMPLIED>
  <!ELEMENT TITLE (#PCDATA)>
  <!ELEMENT PUBL (#PCDATA)>
  <!ATTLIST PUBL YEAR CDATA #IMPLIED
                    MO CDATA #IMPLIED>
  <!ELEMENT NOTE (#PCDATA)>
  

Attribut-Wert Normalisierung

• In Attribut-Werten werden alle vier ``whitespace'' Zeichen (Leerzeichen, Tabulator, Carriage Return, Linefeed) zu Leerzeichen normalisiert.
• Außerdem werden Zeichen-Referenzen und Entity-Referenzen ersetzt.
• Falls der Typ des Attributes nicht CDATA ist, werden Folgen von Leerzeichen durch ein einzelnes Leerzeichen ersetzt, und Leerzeichen am Anfang und am Ende des Attribut-Wertes entfernt.
• Diese Normalisierung erfolgt vor der Typ-Prüfung. Wenn man ``yes'' und ``no'' als mögliche Attribut-Werte deklariert hat, ist zum Beispiel auch folgendes möglich:

  <MEAL VEGETARIAN=" yes ">
  

• Attribut-Wert Normalisierung ist in Abschnitt 3.3.3 [http://www.w3.org/TR/REC-xml#AVNormalize] der Spezifikation definiert.

Dokument-Typ Deklaration

• Die Dokument-Typ Deklaration ist optional. Wenn ein Dokument keine solche Deklaration enthält, kann es allerdings nur ``well-formed'' sein.

  Um ``valid'' zu sein, muß es eine Document Type Deklaration enthalten, und Elemente und Attribute müssen im Dokument gemäß den Einschränkungen dieses Dokumenttyps verwendet werden.

• Die Dokument-Typ Deklaration muß vor dem Start-Tag des äußersten Elementes stehen, und nach der XML-Deklaration.

  Wobei die XML Deklaration eventuell entfallen kann (siehe Kapitel 2). Zwischen der XML-Deklaration und der Dokument-Typ Deklaration sowie zwischen der Dokument-Typ Deklaration und dem Start-Tag des Wurzel-Elementes können nur Kommentare und Processing Instructions stehen.

• Die Dokument-Typ Deklaration kann auf eine Datei verweisen, die die einzelnen Markup Deklarationen (für Elemente, Attribute, etc.) enthält, oder diese Deklarationen können auch direkt in der Dokument-Typ Deklaration enthalten sein. Beide Möglichkeiten können auch kombiniert sein.
• Zum Beispiel würde die Bücherliste in nur einer Datei so aussehen [http://www.informatik.uni-giessen.de/staff/brass/xml00/books4.xml]:

  <?xml version="1.0"?>
  <!-- Kommentar: Einige Bücher zur XML-Definition -->
  <!DOCTYPE BOOKLIST [
           <!ELEMENT BOOKLIST (BOOK)*>
           <!ELEMENT BOOK (AUTHOR+, TITLE, PUBL?, NOTE?)>
           <!ATTLIST BOOK ISBN CDATA #REQUIRED
                             PAGES CDATA #IMPLIED>
           ...
  ]>
  <BOOKLIST>
           <BOOK ISBN="0-13-014714-1" PAGES="1074">
                    <AUTHOR FIRST="Paul" LAST="Prescod"/>
                    <AUTHOR FIRST="Charles" MI="F." LAST="Goldfarb"/>
                    <TITLE>The XML Handbook - 2nd Edition</TITLE>
                    <PUBL YEAR="1999" MO="11">Prentice Hall</PUBL>
                    <NOTE>Contains CD.</TITLE>
           </BOOK>
           ...
  </BOOKLIST>
  

• Die Dokument-Typ Deklaration besteht also aus:
  1. Der Zeichenkette ``<!DOCTYPE''.
  2. Dem Namen des Dokumenttyps. Dieser muß mit dem Namen des Wurzel-Elementes übereinstimmen (im Beispiel: ``BOOKLIST'').
  3. Optional einem Verweis auf eine Datei, die Markup-Deklarationen enthält (``external subset'').
  4. Optional Markup Deklarationen, die in eckige Klammern eingeschlossen sind (``internal subset'').
  5. Einer schließenden spitzen Klammer: ``>''.
• Der Verweis auf eine externe Datei kann aus zwei Teilen bestehen:
  1. Dem Schlüsselwort ``SYSTEM''.
  2. Einer URL (Dies kann auch eine relative URL sein, z.B. einfach ein Dateiname.).

     Die Standards sprechen immer von URI (``Uniform Resource Identifier''). Dies soll allgemeiner als URLs sein, und z.B. auch Dateien verwalten können, die auf mehreren rechnern gespiegelt sind. Es ist aber schon lange ``Work in Progress'', und der einzige wirklich verwendete Spezialfall sind bisher URLs. Wenn URIs aber einmal spezifiziert sind, und auch praktisch verwendet werden, brauchen die XML Standards nicht geändert zu werden, weil sie immer das Wort URI anstatt URL verwenden.

• Auf eine externe Datei kann aber auch mit einem ``PUBLIC''-Identifier verwiesen werden. Dies ist Gegenstand des nächsten Abschnittes.
• Die Syntax von Markup-Deklarationen im ``internal subset'' ist etwas eingeschränkt. Der Grund dafür ist, daß dieser Teil auch von einem ``non-validation parser'' verarbeitet werden muß, der nur die Wohlgeformtheit prüft.

  Markup-Deklarationen in anderen Dateien werden dagegen nur von einem ``validating parser'' gelesen, der ohnehin etwas komplizierter sein muß. Die Einschränkungen beziehen sich auf Entities (im ``internal subset'' sind Entity-Referenzen nur zwischen Markup-Deklarationen erlaubt, können also nur komplette Deklarationen enthalten) und bedingte Abschnitte (im ``internal subset'' verboten) und werden daher im nächsten Kapitel erläutert.

• Werden Markup-Deklarationen im ``internal subset'' angegeben, und gibt es außerdem einen Verweis auf eine Datei mit Markup-Deklarationen, so werden die im Dokument selbst angegebenen Deklarationen zuerst verarbeitet.

  Das mag zunächst der Intuition wiedersprechen, weil sie hinter dem Verweis auf die externen Deklarationen stehen. Aber auf diese Weise können Attribut-Deklarationen aus der externen datei überschrieben werden (die erste Deklaration zählt). Dies kann z.B. für Default-Werte nützlich sein. Noch wichtiger ist dieses Verhalten aber für Entity-Deklarationen (siehe nächstes Kapitel). Zum Beispiel kann man bedingte Abschnitte in der DTD-Datei mit einem im ``internal subset'' deklarierten Entity auswählen.

Public Identifier

• Auf DTDs kann auch mit Hilfe sogenannter ``Public Identifier'' verwiesen werden. Dies ist dann sinnvoll, wenn eine DTD sehr häufig verwendet wird, und man nicht jedesmal über das Netz auf sie zugreifen will.

  Wenn sich XHTML durchsetzt, werden die meisten XML Prozessoren mit einer lokalen Kopie der XHTML DTDs kommen. In den XHTML Dokumenten kann man dann z.B. den Public Identifier "-//W3C//DTD XHTML 1.0 Strict//EN" verwenden. In einer Konfigurationsdatei des XML Prozessors werden Public Identifier auf lokale Dateien abgebildet. Daher muß nicht jedesmal auf den WWW Server des W3C zugegriffen werden. Würde man dagegen den System Identifier "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" verwenden, so wäre das unvermeidbar.

• Da nicht sicher ist, daß jeder XML Prozessor wirklich über lokale Kopien aller DTDs mit Public Identifier verfügt (dann müßte es ja eine zentral verwaltete Liste geben), fordert XML, daß außer dem Public Identifier jedesmal noch eine URL angegeben wird:

  <?xml version="1.0"?>
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" >
  <HTML>
           ...
  </HTML>
  

• Der Verweis auf eine externe DTD hat also zwei mögliche Formen:
  1. Das Schlüsselwort ``SYSTEM'' und eine URL.
  2. Das Schlüsselwort ``PUBLIC'', ein Public Identifier und eine URL.
• Ein Public Identifier besteht aus folgenden Teilen:
  1. Zuerst ein Plus-Zeichen (``+''), falls der ``Besitzer'' der DTD nach ISO 9070 registriert ist, ansonsten ein Minus-Zeichen.

     Zum Beispiel ist nicht einmal das W3C registriert.

  2. Dann nach dem ersten doppelten Schrägstrich der Name des Besitzers der DTD (also die Organisation, die diese DTD definiert hat).
  3. Dann nach einem weiteren doppelten Schrägstrich die Zeichenfolge ``DTD''.

     Zum Beispiel gibt es Public Identifier auch für Notationen, siehe Kapitel 4.

  4. Dann nach einem Leerzeichen der Name der DTD (oder eine kurze Beschreibung).
  5. Schließlich nach einem dritten doppelten Schrägstrich ein Kürzel für die Sprache, in der die DTD verfaßt ist (zum Beispiel die Namen der Tags). Dies ist ein Zwei-Zeichen Code nach ISO 639, zum Beispiel ``EN'' für Englisch und ``DE'' für Deutsch.

     Normalerweise schreibt man die Sprachkürzel klein und die Landeskürzel groß, aber bei DTDs scheint die große Schreibweise üblich zu sein.

  An jeder Stelle, an der ein Leerzeichen stehen darf, kann auch eine beliebige Folge von Leerplatz-Zeichen stehen (zum Beispiel ein Zeilenumbruch, Public Identifier sind oft sehr lang). Auch wird Leerplatz am Anfang und am Ende entfernt, bevor ein Vergleich mit den in der Konfigurationsdatei eingetragenen Public Identifiern durchgeführt wird.

• In der XML Welt scheint es kein besonders großes Interesse für Public Identifier zu geben, weil URLs ja auch global eindeutig sind und funktionieren.

  Public Identifier waren wichtig für SGML in der Vor-WWW Zeit. Die oben genannten Leistungsprobleme könnte man vielleicht durch lokale Pufferung der DTD-Dateien umgehen.

© Stefan Brass (sbrass@sis.pitt.edu), 11. September 2000

Original URL: http://www.informatik.uni-giessen.de/staff/brass/xml00/c3_dtd.xml