Ziel Document Type Defintions (DTDs) legen zustzliche Einschrnkungen fr XML-Dokumente fest, die ber die reine Wohlgeformtheit hinaus gehen. Aus der Spezifikation, Abschnitt2.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-xmlsec-prolog-dtd Zum Beispiel definieren DTDs, welche Element-Typen (Tags) es gibt, welche Elemente im Inhalt welcher anderen Elemente vorkommen knnen (und ob sie wiederholbar oder optional sind, welche Reihenfolge eingehalten werden mu), welche Elemente Text-Daten enthalten knnen, welche Attribute ein Element-Typ hat und was mgliche Werte fr ein Attribut sind. Im Prinzip ist eine DTD einfach eine kontextfreie Grammatik fr die Daten. Man kann eine gegebene DTD direkt in eine kontextfreie Grammatik (CFG) bersetzen. Dabei fhrt man fr jeden Element-Typ ein entsprechendes Nichtterminal-Symbol ein. Die Regel, da Attribute in beliebiger Reihenfolge angegeben werden knnen, aber keines mehrfach, ist in der CFG allerdings nur umstndlich auszudrcken (Auerdem knnen 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 behlt dann mit den Start- und End-Tags Markierungen zurck, die den ganzen Ableitungsbaum im Ergebniswort codieren. Man knnte 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 nher erlutert (siehe unter ``Dokument-Typ Deklaration'') Beispiel (Datei booklist.dtd) http://www.informatik.uni-giessen.de/staff/brass/xml00/booklist.dtd: Document Type Definition fr Literaturlisten BOOKLIST (BOOK)* BOOK (AUTHOR+, TITLE, PUBL?, NOTE?) BOOK ISBN CDATA PAGES CDATA AUTHOR EMPTY AUTHOR FIRST CDATA MI CDATA LAST CDATA TITLE () PUBL () PUBL YEAR CDATA MO CDATA NOTE () Folgende Datei http://www.informatik.uni-giessen.de/staff/brass/xml00/books2.xml basiert auf dieser DTD und ist ``valid'': version=1.0 Kommentar: Einige Bcher zur XML-Definition 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 TITLEThe XML Handbook - 2nd EditionTITLE PUBL YEAR=1999 MO=11Prentice HallPUBL NOTEContains CD.TITLE BOOK BOOK ISBN=1-56592-709-5 PAGES=107 AUTHOR FIRST=Robert LAST=Eckstein TITLEXML Pocket ReferenceTITLE PUBL YEAR=1999 MO=10O'ReillyPUBL BOOK BOOK ISBN=0-13-082676-6 PAGES=368 AUTHOR FIRST=Bob LAST=DuCharme TITLEXML: The Annotated SpecificationTITLE PUBL YEAR=1998 MO=12 Prentice HallPUBL BOOK BOOKLIST

Element-Deklarationen Eine Element-Deklaration besteht aus der Zeichenfolge ``!ELEMENT'', dem Namen des Element-Typs, einer Spezifikation ber das Format des Inhaltes des Elementes (was also zwischen ffnendem und schlieendem Tag stehen darf, ``content model'') und dem Zeichen ``''. Alle Deklarationen in XML beginnen mit ``!''. Fr die Inhalts-Spezifikation gibt es vier Mglichkeiten: kein Inhalt erlaubt, beliebiger Inhalt, nur Elemente (mit vorgeschriebener Struktur) (``element content''), Elemente und Text (mit Angabe welche Elemente zulssig sind) (``mixed content''). Natrlich kann ein Element bei der dritten Mglichkeit (``element content'') indirekt Text enthalten, nmlich innerhalb dieser Elemente. Aber die Kind-Knoten in der Baum-Darstellung sollen dann smtlich Element-Knoten sein, keine Text-Knoten. Die Festlegung, da ein Element leer sein mu, geschieht mit dem Schlsselwort ``EMPTY'': AUTHOR EMPTY Es wre brigens ein Syntaxfehler, Klammern um das Wort ``EMPTY'' zu setzen. In diesem Fall mten ``AUTHOR''-Elemente jeweils genau ein Element vom Typ ``EMPTY'' enthalten. Man beachte auch, da wenn man Start- und End-Tag fr ein als leer deklariertes Element verwendet, dazwischen nicht einmal ein Leerzeichen stehen darf. Ein anderer hufiger Spezialfall ist, da ein Element nur Text enthalten kann, aber keine weiteren Elemente: TITLE () Dies zhlt formal als ``mixed content'', obwohl es gar nicht gemischt ist (reiner Text). ``'' steht fr ``parsed character data''. Im Unterschied zu CDATA (``character data'')-Abschnitten mu der Inhalt hier syntaktisch analysiert werden, um zu prfen, da auch wirklich keine Elemente darin vorkommen (und um Entity-Referenzen zu ersetzen). Hier sind brigens die Klammern ntig, sonst wre es ein Syntaxfehler. (Ich kenne keine einleuchtende Erklrung, warum die Klammern ntig sind.) Die Markierung ``'' ist ntig, um es als Schlsselwort zu kennzeichnen. Lt man es weg, so wrde der Parser statt dessen ein Element vom Typ ``PCDATA'' erwarten. Oft enthlt ein Element im wesentlichen Text, von dem aber Teile in weitere Tags eingeschlossen sind. Zum Beispiel knnte es sein, da man definierende Vorkommen von Worten im Text markieren mchte (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 wre folgender Inhalt mglich: PEin Komitee unter Leitung von NAMECharles GoldfarbNAME entwickelte DEFSGMLDEF, die Standard Generalized Markup Language, von 1978 bis 1986 zu einem internationalen Standard. P Solcher Inhalt wird in folgender Form definiert: P ( | DEF | NAME)* Der senkrechte Strich ``|'' bedeutet ``oder'', der Stern``*'' bedeutet null oder mehrmalige Wiederholung. Der Inhalt von Elementen des TypsP ist also eine beliebige Folge von Text-Daten, Elementen vom TypDEF und Elementen vom TypNAME. Die Elemente mssen nicht unbedingt vorkommen und knnen aber auch mehrfach vorkommen. XML bietet keine Mglichkeit, zu spezifizieren, da die Elemente vorkommen mssen, nur in bestimmter Reihenfolge vorkommen drfen, oder nicht mehrfach vorkommen drfen. (Alles dies wird aber mglich bei ``element content'', wenn man den Text also noch in Elemente einschlieen wrde.) Die Inhalts-Spezifikation mu brigens genau so aussehen: Obwohl ``|'' normalerweise kommutativ sein sollte, mu ``'' ganz am Anfang stehen. Fr 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 schlieenden Klammer. Zwischen ``)'' und ``*'' darf kein Leerzeichen stehen. Das ist schon ein bichen merkwrdig. Am einfachsten merktman es sich so, da Leerzeichen berall erlaubt sind, wo man es erwarten wrde, auer vor dem Wiederholungssymbol. Beliebiger Inhalt wird mit dem Schlsselwort ``ANY'' erlaubt: EXAMPLE ANY Es scheint, da dies quivalent ist zu EXAMPLE (|...)* Dabei ist ... eine Aufzhlung aller deklarierten Element-Typen. Auch bei ANY mssen alle im Dokument verwendeten Element-Typen mit ``!ELEMENT'' deklariert sein, sonst ist das Dokument nicht gltig. Man beachte schlielich noch, da kein Element-Typ mehr als einmal in einer DTD definiert sein darf.

Inhalts-Spezifikation fr ``Element Content'' Wenn ein Element-Typ als Inhalt nur andere Elemente haben kann, aber nicht direkt Text, spricht man von ``Element Content''. Fr diesen Fall bietet XML recht mchtige Definitionsmglichkeiten fr die Struktur des Inhalts. Man kann Auswahl``|'' und Sequenz``,'' verwenden, diese auch (fast) beliebig schachten, und fr jede Gruppe definieren, ob sie optional ist (``?'', null oder einmal), optional und wiederholbar (``*'', null oder mehrfach), oder notwendig und wiederholbar (``+'', einmal oder mehrfach). 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 mssen: BOOK (AUTHOR, TITLE, PUBLISHER) Sequenz hat also die allgemeine Syntax ``(...,...,...)''. Sie erzwingt eine Reihenfolge frn, n1, Elemente. Links und rechts der Kommata sind Leerzeichen erlaubt, aber nicht ntig. Fr jedes Element der Sequenz (wie auch fr die Sequenz als ganzes) kann man Optionalitt und Wiederholbarkeit definieren, z.B.: 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). Mchte 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 wrde, auer vor dem Wiederholungs-/Optionalitts-Symbol. Leerzeichen sind natrlich auch nicht nach , ! oder ? erlaubt (aber schon vor ). Man kann auch die ganze Liste wiederholbar machen, z.B.: AUTHORS (FIRST, LAST)+ Dies erlaubt mehrere Paare von Vorname und Nachname, z.B.: AUTHORSFIRSTUdoFIRSTLASTLipeckLAST FIRSTStefanFIRSTLASTBrassLASTAUTHORS Man beachte, da in dem letzten Beispiel der Leerplatz (neue Zeile, Tabulator) zwischen den Elementen zulssig ist, obwohl die Inhaltsspezifikation reinen ``Element Content'' vorschreibt. Dies vereinfacht die Eingabe und erlaubt, XML Code schner 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 fr ``Element Content'' bekommen ihre Mchtigkeit 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 mglich: BOOK ((FIRST, LAST)+, TITLE, PUBLISHER?) Es mssen dann zunchst Paare von Vornamen und Nachnamen angegeben werden (mindestens einmal), dann ein Titel, und zum Schlu mglicherweise ein Verlag. Neben der mit ``,'' markierten Sequenz gibt es auch die mit ``|'' markierte Auswahl. Zum Beispiel bedeutet ``(PUBL|UNI)'', 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 mglich, z.B.: BOOK ((FIRST, LAST)+, TITLE, (PUBLISHER|UNI)?) Dies erlaubt anstelle der Angabe eines Verlages auch die Angabe einer Universitt (etwa fr technische Berichte). Aufgrund des ``?'' kann die Angabe aber auch ganz entfallen. Aufgabe: Wie kann man definieren, da ein ElementA 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 dafr eine eigene Notation, die aber zur Vereinfachung in XML weggelassen wurde. Jede Inhaltsspezifikation fr ``Element Content'' mu mindestens ein Paar Klammern enthalten. Selbst wenn jedes Element A das Element B genau einmal enthalten soll, mu man folgendes schreiben: A (B) Diese Situation kommt allerdings nicht besonders hufig vor. Namen auerhalb von Klammern sind nicht mglich, da es dann zur Kollision mit ``EMPTY'' und ``ANY'' kommen kann. Wiederholungs-/Optionalitts-Angaben sind sowohl nach Element-Typen als auch nach der schlieenden Klammer einer Auswahl oder Sequenz mglich. Zum Beispiel ist folgendes quivalent: A (B*) A (B)* Dagegen ist folgendes natrlich nicht quivalent: A (B*, C*) A (B, C)* Element-Typ Deklarationen sind in Abschnitt3.2 der XML Spezifikation behandelt http://www.w3.org/TR/REC-xmlelemdecls.

``Deterministic Content Models'' Schlielich fordert XML ``deterministic content models''. Das bedeutet, da der XML Parser allein durch ansehen des nchsten Elementes in der Eingabe entscheiden kann, welchen Weg er bei einer Auswahl verfolgen mu. Zum Beispiel wre folgendes nicht zulssig: 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 lsen kann (man kann jeden nichtdeterministischen endlichen Automaten in einen deterministischen endlichen Automaten umwandeln). Aber der XML Standard fordert aus Kompatibilittsgrnden mit existierenden SGML Systemen diese Einschrnkung. Es macht die Entwicklung von Parsern etwas einfacher, wenn diese Umwandlung nicht ntig ist. Dafr mu der XML Benutzer die Inhaltsspezifikation dann so aufschreiben: EXAMPLE (A, (B | C)) Dies beschreibt das gleiche Format fr den Inhalt, ist aber ein ``deterministic content model''. Das Problem tritt brigens nicht nur bei Auswahl auf. Auch das folgende Beispiel wre unzulssig: EXAMPLE2 ((A, B)*, (A, C)) Aufgabe: Geben Sie eine quivalente deterministische Inhalts-Spezifikation an. (Mndlich:) Aufbau des endlichen Automaten fr eine Inhaltsspezifikation. AnhangE der XML Spezifikation beschftigt sich mit ``Deterministic Content Models'' http://www.w3.org/TR/REC-xmldeterminism.

Definition von Attributen Man kann Attribute fr einen Elementtyp in der folgenden Form definieren: AUTHOR FIRST CDATA MI CDATA LAST CDATA Die Deklaration von Attributen eines Element-Typs besteht aus der Zeichenkette ``!ATTLIST'', dem Namen des Element-Typs, ein oder mehreren Attribut-Deklarationen und dem Zeichen ``''. Tatschlich lt 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: dem Namen des Attributes, dem Typ des Attributes und einer Default Deklaration. Ein wichtiger Typ von Attributen ist ``CDATA''. Es sind dann beliebige Zeichenketten erlaubt (die aber kein ``'' enthalten knnen, und ``'' nur fr Entity-Referenzen). Weitere Typen von Attributen werden unten erlutert. Default-Deklarationen haben vier Formen: , , ein Default-Wert, mit der Angabe eines konstanten Wertes. bedeutet, da das Start-Tag fr jedes Element dieses Types eine Attributwert-Angabe fr dieses Attribut enthalten mu. In SGML war das Zeichen ``'' notwendig, weil ``REQUIRED'' auch ein Default-Wert (s.u.) sein konnte. In XML mssen die Default-Werte dagegen immer in Anfhrungszeichen eingeschlossen werden, so da auch ohne ``'' keine Verwechselung mglich wre. Aber aus Kompatibilittsgrnden wollte man die Schlsselwrter nicht ndern. 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 fr das Attribut gibt (es wird also nicht ein Default-Wert angenommen). Es wird dann davon ausgegangen, da die Anwendung selbst einen Wert fr das Attribut berechnen kann (etwa eine fortlaufende Kapitel-Nummer), daher der Name ``Implied''. Dies ist aber nicht erforderlich, und das Schlsselwort ``OPTIONAL'' wre 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 fr das Attribut. Zum Beispiel: 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 Mglichkeit ist, einen Wert fest vorzuschreiben: P xml:space CDATA 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 fr ``globale Attribute'', die also mehr als einem Element-Typ zukommen. Fr die verschiedenen Element-Typen knnen dann unterschiedliche Werte deklariert werden. Zum Beispiel die XLink-Spezifikation macht von solchen Attributen Gebrauch, um Element-Typen als Hyperlinks zu kennzeichnen. Es ist zulssig, mehr als eine Attribut-Liste fr einen Element-Typ zu haben. Man kann sogar mehr als eine Deklaration fr das gleiche Attribut haben, in welchem Fall die erste Deklaration ausschlaggebend ist, und alle weiteren Deklarationen ignoriert werden. Allerdings wird von beiden Mglichkeiten abgeraten, und XML Parser knnen eine Option anbieten, in solchen Fllen eine Warnung auszugeben. Attribut-Deklarationen werden in Abschnitt3.3 der Spezifikation behandelt http://www.w3.org/TR/REC-xmlattdecls.

Daten-Typen fr Attribute CDATA: Beliebiger String (``character data''). Aufzhlungen, zum Beispiel ``(yes|no)'': Das Attribut mu einen der angegebenen Werte haben. Die Werte mssen Folgen von Buchstaben, Zifferen, Unterstrich``'', Bindestrich``-'', Punkt``.'' und Doppelpunkt``:'' sein. Dies sind die gleichen Zeichen, die in Namen verwendet werden drfen, aber es gibt keine Beschrnkung bezglich des ersten Zeichens. Zum Beispiel knnen numerische Werte wie 2000 verwendet werden. Beispiel: MEAL VEGETARIAN (yes|no) no COOKED (rare|medium|well-done) Man beachte, da in der Aufzhlung keine Anfhrungszeichen erlaubt sind, aber man einen Default-Wert hinterher in Anfhrungszeichen angeben mu. ID: Dies sind eindeutige Namen fr das Element. Attribut-Werte mssen die gleichen Einschrnkungen wie Namen erfllen, zustzlich 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: BOOK ID ID Es macht keinen Sinn, fr Attribute dieses Typs einen Default-Wert anzugeben, und die Spezifikation schreibt auch vor, da sie nur zusammen mit und verwendet werden knnen. Kein Element-Typ kann mehr als ein Attribut dieses Typs haben. Dies ist ein Problem fr XHTML, weil in HTML jedes Element ein Attribut ``ID'' hat (zur Identifikation in Javascript-Programmen), aber ``A''-Elemente noch zustzlich das Attribute ``NAME'' haben, das ebenfalls eine eindeutig sein mu. Man beachte, da Nummern nicht zulssig als Wert von ID-Attributen sind. Das ist schade, weil in Datenbanken hufig Kundennummern, Angestellten-Nummern, etc.verwendet werden. Man kann sich natrlich behelfen, indem man einen Buchstaben voranstellt, z.B.``K1001'' fr Kunden1001. Das kann auch ntzlich sein, weil IDs in XML global eindeutig sein mssen. 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 Schlssel dagegen immer nur auf eine Relation. IDREF: Attribute dieses Typs verweisen auf andere Elemente. Attribut-Werte mssen wieder zulssige Namen sein, und sie mssen auerdem im XML Dokument als Wert eines Attributes des Typs ID vorkommen. Natrlich 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, vorwrts-Referenzen sind mglich. Es ist in XML DTDs nicht mglich, vorzuschreiben, auf welchen Typ von Elementen verwiesen wird. Natrlich 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 wrde keine Fehlermeldung ausgeben, wenn so ein Verweis einmal auf einen Kunden zeigt. IDREFS: Attribute dieses Typs verweisen auf eine Menge anderer Elemente. Attribut-Werte mssen eine durch Leerplatz (Leerzeichen etc.) getrennte Liste von Namen sein. Wie vorher mu jeder einzelne Name im XML Dokument als Wert eines Attributes vom TypID auftreten. NMTOKEN: Attribut-Werte mssen Folgen von Buchstaben, Ziffern, und den vier Zeichen ``'', ``-'', ``.'' und ``:'' sein. Es gibt wieder keine Beschrnkung bezglich des ersten Zeichens. Zahlen wie 3.14 sind also zulssig, aber zum Beispiel auch ``.:X-''. DTDs erlauben nicht, vorzuschreiben, da nur numerische Werte fr ein Attribut zulssig sind (siehe aber den Vorschlag fr 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 Aufzhlungen von Notationen. Diese werden im nchsten Kapitel erlutert. Abschnitt3.3.1 http://www.w3.org/TR/REC-xmlsec-attribute-types behandelt Datentypen fr Attribute.

Beispiel fr ID/IDREF Wenn man noch weitere Informationen ber Autoren erfassen will, z.B.eine EMail-Adresse oder Homepage (soweit bekannt), dann wren diese Informationen redundant dargestellt, wenn einige Autoren mehrere Bcher geschrieben haben. Im Datenbank-Entwurf, besonders bei der Normalisierung, versucht man solche Redundanzen zu vermeiden. Redundanzen fhren hufig zu Inkonsistenzen und doppelter Arbeit. Eine Lsung ist, die Information ber Autoren getrennt von der Information ber Bcher zu erfassen und in den Buch-Elementen auf die Autor-Elemente zu verweisen: http://www.informatik.uni-giessen.de/staff/brass/xml00/books3.xml: version=1.0 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 TITLEThe XML Handbook - 2nd EditionTITLE PUBL YEAR=1999 MO=11Prentice HallPUBL NOTEContains CD.TITLE BOOK BOOK AUTHORS=RE ISBN=1-56592-709-5 PAGES=107 TITLEXML Pocket ReferenceTITLE PUBL YEAR=1999 MO=10O'ReillyPUBL BOOK BOOK AUTHORS=BC ISBN=0-13-082676-6 PAGES=368 TITLEXML: The Annotated SpecificationTITLE PUBL YEAR=1998 MO=12 Prentice HallPUBL BOOK BOOKLIST Die DTD dazu sieht so aus http://www.informatik.uni-giessen.de/staff/brass/xml00/books3.dtd: BOOKLIST (AUTHOR | BOOK)* AUTHOR EMPTY AUTHOR ID ID FIRST CDATA MI CDATA LAST CDATA BOOK (TITLE, PUBL?, NOTE?) BOOK AUTHORS IDREFS ISBN CDATA PAGES CDATA TITLE () PUBL () PUBL YEAR CDATA MO CDATA NOTE ()

Attribut-Wert Normalisierung In Attribut-Werten werden alle vier ``whitespace'' Zeichen (Leerzeichen, Tabulator, Carriage Return, Linefeed) zu Leerzeichen normalisiert. Auerdem 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-Prfung. Wenn man ``yes'' und ``no'' als mgliche Attribut-Werte deklariert hat, ist zum Beispiel auch folgendes mglich: MEAL VEGETARIAN= yes Attribut-Wert Normalisierung ist in Abschnitt3.3.3 http://www.w3.org/TR/REC-xmlAVNormalize der Spezifikation definiert.

Dokument-Typ Deklaration Die Dokument-Typ Deklaration ist optional. Wenn ein Dokument keine solche Deklaration enthlt, kann es allerdings nur ``well-formed'' sein. Um ``valid'' zu sein, mu es eine Document Type Deklaration enthalten, und Elemente und Attribute mssen im Dokument gem den Einschrnkungen dieses Dokumenttyps verwendet werden. Die Dokument-Typ Deklaration mu vor dem Start-Tag des uersten Elementes stehen, und nach der XML-Deklaration. Wobei die XML Deklaration eventuell entfallen kann (siehe Kapitel2). Zwischen der XML-Deklaration und der Dokument-Typ Deklaration sowie zwischen der Dokument-Typ Deklaration und dem Start-Tag des Wurzel-Elementes knnen nur Kommentare und Processing Instructions stehen. Die Dokument-Typ Deklaration kann auf eine Datei verweisen, die die einzelnen Markup Deklarationen (fr Elemente, Attribute, etc.) enthlt, oder diese Deklarationen knnen auch direkt in der Dokument-Typ Deklaration enthalten sein. Beide Mglichkeiten knnen auch kombiniert sein. Zum Beispiel wrde die Bcherliste in nur einer Datei so aussehen http://www.informatik.uni-giessen.de/staff/brass/xml00/books4.xml: version=1.0 Kommentar: Einige Bcher zur XML-Definition BOOKLIST BOOKLIST (BOOK)* BOOK (AUTHOR+, TITLE, PUBL?, NOTE?) BOOK ISBN CDATA PAGES CDATA ... BOOKLIST BOOK ISBN=0-13-014714-1 PAGES=1074 AUTHOR FIRST=Paul LAST=Prescod AUTHOR FIRST=Charles MI=F. LAST=Goldfarb TITLEThe XML Handbook - 2nd EditionTITLE PUBL YEAR=1999 MO=11Prentice HallPUBL NOTEContains CD.TITLE BOOK ... BOOKLIST Die Dokument-Typ Deklaration besteht also aus: Der Zeichenkette ``!DOCTYPE''. Dem Namen des Dokumenttyps. Dieser mu mit dem Namen des Wurzel-Elementes bereinstimmen (im Beispiel: ``BOOKLIST''). Optional einem Verweis auf eine Datei, die Markup-Deklarationen enthlt (``external subset''). Optional Markup Deklarationen, die in eckige Klammern eingeschlossen sind (``internal subset''). Einer schlieenden spitzen Klammer: ``''. Der Verweis auf eine externe Datei kann aus zwei Teilen bestehen: Dem Schlsselwort ``SYSTEM''. 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 knnen, 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 gendert 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 nchsten Abschnittes. Die Syntax von Markup-Deklarationen im ``internal subset'' ist etwas eingeschrnkt. Der Grund dafr ist, da dieser Teil auch von einem ``non-validation parser'' verarbeitet werden mu, der nur die Wohlgeformtheit prft. Markup-Deklarationen in anderen Dateien werden dagegen nur von einem ``validating parser'' gelesen, der ohnehin etwas komplizierter sein mu. Die Einschrnkungen beziehen sich auf Entities (im ``internal subset'' sind Entity-Referenzen nur zwischen Markup-Deklarationen erlaubt, knnen also nur komplette Deklarationen enthalten) und bedingte Abschnitte (im ``internal subset'' verboten) und werden daher im nchsten Kapitel erlutert. Werden Markup-Deklarationen im ``internal subset'' angegeben, und gibt es auerdem einen Verweis auf eine Datei mit Markup-Deklarationen, so werden die im Dokument selbst angegebenen Deklarationen zuerst verarbeitet. Das mag zunchst der Intuition wiedersprechen, weil sie hinter dem Verweis auf die externen Deklarationen stehen. Aber auf diese Weise knnen Attribut-Deklarationen aus der externen datei berschrieben werden (die erste Deklaration zhlt). Dies kann z.B.fr Default-Werte ntzlich sein. Noch wichtiger ist dieses Verhalten aber fr Entity-Deklarationen (siehe nchstes Kapitel). Zum Beispiel kann man bedingte Abschnitte in der DTD-Datei mit einem im ``internal subset'' deklarierten Entity auswhlen.

Public Identifier Auf DTDs kann auch mit Hilfe sogenannter ``Public Identifier'' verwiesen werden. Dies ist dann sinnvoll, wenn eine DTD sehr hufig 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. Wrde man dagegen den System Identifier http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd verwenden, so wre das unvermeidbar. Da nicht sicher ist, da jeder XML Prozessor wirklich ber lokale Kopien aller DTDs mit Public Identifier verfgt (dann mte es ja eine zentral verwaltete Liste geben), fordert XML, da auer dem Public Identifier jedesmal noch eine URL angegeben wird: 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 mgliche Formen: Das Schlsselwort ``SYSTEM'' und eine URL. Das Schlsselwort ``PUBLIC'', ein Public Identifier und eine URL. Ein Public Identifier besteht aus folgenden Teilen: 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. Dann nach dem ersten doppelten Schrgstrich der Name des Besitzers der DTD (also die Organisation, die diese DTD definiert hat). Dann nach einem weiteren doppelten Schrgstrich die Zeichenfolge ``DTD''. Zum Beispiel gibt es Public Identifier auch fr Notationen, siehe Kapitel4. Dann nach einem Leerzeichen der Name der DTD (oder eine kurze Beschreibung). Schlielich nach einem dritten doppelten Schrgstrich ein Krzel fr die Sprache, in der die DTD verfat ist (zum Beispiel die Namen der Tags). Dies ist ein Zwei-Zeichen Code nach ISO639, zum Beispiel ``EN'' fr Englisch und ``DE'' fr Deutsch. Normalerweise schreibt man die Sprachkrzel klein und die Landeskrzel gro, aber bei DTDs scheint die groe 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 durchgefhrt wird. In der XML Welt scheint es kein besonders groes Interesse fr Public Identifier zu geben, weil URLs ja auch global eindeutig sind und funktionieren. Public Identifier waren wichtig fr SGML in der Vor-WWW Zeit. Die oben genannten Leistungsprobleme knnte man vielleicht durch lokale Pufferung der DTD-Dateien umgehen.