Ziel In diesem und den nchsten beiden Kapiteln wollen wir erklren (definieren), welche Zeichenfolgen syntaktisch korrekte XML-Dokumente sind. Zum Beispiel ist ein syntaktisch korrektes XML-Dokument: version=1.0 Kommentar: Einige Bcher zur XML-Definition xml-stylesheet type=text/xsl href=booksie.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 Diese Datei steht unter der URL http://www.informatik.uni-giessen.de/staff/brass/xml00/books1.xml im Web. Sie verwendet ein Stylesheet, das in Kapitel7 erlutert wird. Eine Version ohne Stylesheet ist unter http://www.informatik.uni-giessen.de/staff/brass/xml00/books0.xml verfgbar. Der Internet Explorer zeigt dann die Baumstruktur (s.u.) an, mit der Mglichkeit, Teilbume auszublenden oder anzuzeigen. Wir werden die XML-Syntax hier mit Prosa ``halb-formal'' definieren. Es sei aber ausdrcklich auf die im Web verfgbare XML-Spezifikation verwiesen, die eine kontextfreie Grammatik fr XML enthlt (plus einige zustzliche Einschrnkungen in Prosa): http://www.w3.org/TR/REC-xml. Kontextfreie Grammatiken sind ein wichtiges Werkzeug fr Informatiker. Ich wundere mich, wenn ein Buch, das sich ``Referenz`` nennt, nicht die Grammatik fr XML enthlt. Ich hatte, nachdem ich eine XML Definition in Prosa gelesen hatte, durchaus noch einige Fragen, die sich nur anhand der Grammatik klren lieen. Die Grammatik hat insbesamt 89 Produktionen und die ganze XML Spezifikation hat 36Seiten.

Zwei Stufen Syntaktischer Korrektheit Der XML-Standard definiert zwei Stufen syntaktischer Korrektheit. Well-Formed: Alles, was sich ohne ``Document Type Definition'' (Grammatik) prfen lt, z.B.die korrekte Klammerstruktur der Tags. Valid: Zustzlich korrekte Verwendung der Tags gem der DTD. Viele existierende Parser prfen nur die Wohlgeformtheit. Dies ist zum Beispiel ausreichend, um die DOM-Datenstruktur aufzubauen, und auch fr die Darstellung im Browser (zum Beispiel mit XSL). Die Gltigkeit bezglich einer Grammatik ist ein zustzlicher Integritts-Test. Zum Beispiel reicht die Wohlgeformtheit aus, ein Stylesheet anzuwenden, aber man wird nicht das gewnschte Ergebnis bekommen, wenn das Eingabedokument nicht der Grammatik gengt, die bei der Entwicklung des Stylesheets angenommen wurde. Da SGML auch wegen seiner Komplexitt im Web nicht akzeptiert wurde, war es wohl sinnvoll, Browser-Herstellern zu ermglichen, die DTD zu ignorieren. Tatschlich mu auch ein non-validating Parser die syntaktische Korrektheit der DTD-Teilmenge im Dokument selbst prfen, und auch dort definierte Entities, Default-Werte von Attributen etc.bercksichtigen. Es ist also nicht ganz richtig, da die DTD vllig ignoriert werden kann. Bestimmte syntaktische Komplikationen sind aber nur in externen DTDs erlaubt, die ignoriert werden knnen. Die Syntax-Regeln, die die DTD vorschreibt, brauchen auch nicht im Dokument geprft zu werden. Bei der Entwicklung von DTDs schreibt man hufig zunchst ein Beispiel-Dokument auf. Dies ist auch ohne DTD schon syntaktisch korrektes XML. Theoretisch knnte man XML-Dateien ganz ohne DTDs verwenden, aber die Weiterverarbeitung der Daten wird sehr unsicher und schwierig, wenn man keine DTD hat. Der Name ``valid'' ist vielleicht etwas unglcklich: Nur wohlgeformtes XML ist nicht automatisch ``invalid''. Nur wenn eine DTD angegeben ist, und das Dokument ihr nicht gengt, knnte man von ``invalid'' sprechen. In der XML-Spezifikation definiert Abschnitt5.1 http://www.w3.org/TR/REC-xmlproc-types die Anforderungen an ``validating'' und ``non-validating'' XML-Prozessoren. Die Anforderungen fr ``well-formed'' und ``valid'' XML sind dadurch geregelt, da zwar beide die gleiche kontext-freie Grammatik verwenden, aber bei den (kontext-sensitiven) Zusatz-Bedingungen zwischen ``well-formedness constraints'' (mu jedes XML Dokument erfllen) und ``validity constraints'' (mssen nur ``valid'' XML-Dokumente erfllen) unterschieden wird.

Zeichensatz Ein XML-Dokument ist eine Folge von Zeichen. Gltige Zeichen sind TAB (tabulator), CR (carriage return), LF (line feed), und die grafischen Zeichen des Unicode Standards und ISO/IEC10646 Standards (``Universal Multiple-Octed Coded Character Set''). Zum Beispiel sind Escape und BEL nicht erlaubt. Der Unicode-Standard wurde von einer Gruppe von Computer-Herstellern entwickelt (z.B.IBM, HP, ORACLE, Microsoft, Apple, SUN), um Zeichen einheitlich mit 16Bits zu reprsentieren http://www.unicode.org. Der Unicode Standard stimmt mit der UCS-2/UTF-16 (2Byte) Variante des ISO/IEC10646 Standards berein. Beide Komitees arbeiten zusammen, um zu verhindern, da die beiden Standards auseinanderlaufen. Man mu die Menge der erlaubten Zeichen von ihrer Codierung trennen. XML erlaubt durchaus verschiedene Codierungen fr die XML-Dokumente. Alle XML Prozessoren mssen die UTF-8 und UTF-16 Codierungen des ISO/IEC10646 Standards verarbeiten knnen. UTF-8 arbeitet mit einem Byte fr Zeichen mit Nummer bis127 (x007F), zwei Byte fr Zeichen mit Nummer zwischen 128 und 2047 (x07FF), drei Byte fr Zeichen mit Nummer zwischen 2048 und 65535 (xFFFF), und vier Bytes fr ``Surrogates'' (bisher nicht benutzt). UTF-16 verwendet zwei Byte fr jedes Zeichen (und vier Bytes fr ``Surrogate Pairs''). UTF-16 Dokumente mssen mit xFEFF beginnen, und knnen so von UTF-8 Dokumenten unterschieden werden. Der XML Standard erklrt im AnhangF (``Autodetection of Character Encodings''), wie verschiedene Codierungen erkannt werden knnen. Der Standard schreibt vor, da, sofern nicht UTF-8 oder UTF-16 verwendet werden, die ersten Zeichen ?xml ...? sein mssen. Wei man, wie diese Zeichen in verschiedenen Codierungen aussehen, so kann man genug erkennen, um die Codierungs-Deklaration zu verstehen, die in dieser XML-Deklaration enthalten sein mu. Will man z.B.mit ISO Latin 8859/1 arbeiten, so schreibt man ganz am Anfang des Dokumentes: version=1.0 encoding=ISO-8859-1. Allerdings kann es sein, da ein XML-Prozessor diese Codierung nicht kennt und das Dokument zurckweist. ASCII (``American Standard Code for Information Interchange'') ist eine Teilmenge von UTF-8. Solange man also nur normale Zeichen verwendet (z.B.keine Umlaute), braucht man sich ber die Codierung also keine groen Gedanken machen. Wenn man nicht auf einem IBM Grorechner mit EBCDIC arbeitet. Man kann in XML die Nummer eines Zeichens im Unicode verwenden, um das Zeichen darzustellen. Das ist wichtig, wenn man mit einer Zeichencodierung arbeitet, die nicht den ganzen Unicode-Zeichensatz enthlt. Zum Beispiel hat das Zeichen ``'' in Unicode die Nummer 228 (hexadezimal E4). Es kann als ``228'' oder ``xE4'' notiert werden (wenn man z.B.nur den ASCII Zeichensatz verwendet). Unicode von den Zeichencodes her auch eine Obermenge von ISO Latin8859/1. Das ntzt allerdings nicht viel, da die UTF-8 Codierung nicht kompatibel ist: Umlaute werden mit zwei Bytes dargestellt, da ihr Code grer als 127 ist. In der Ausgabe erscheinen dann zwei merkwrdige Zeichen fr jeden Umlaut (wenn das Terminal nicht Unicode-kompatibel ist). Die 2-Byte Codierung von UTF-8 kann bis zu 11 Bits darstellen: Das erste Byte startet mit den Bits ``110'' und enthlt dann die hherwertigen 5 Bits der Unicode-Nummer, das zweite Byte startet mit den Bits ``10'' und enthlt dann die niederwertigen 6 Bits der Unicode-Nummer. Die 3-Byte Codierung kann dann alle 16Bits darstellen: Das erste Byte startet mit ``1110'' gefolgt von den 4hchstwertigen Bits der Unicode-Nummer, dann folgen zwei Bytes, die beide mit ``10'' beginnen und jeweils 6 Bits enthalten. Zeichenstze werden in der XML-Spezifikation in den Abschnitten2.2 http://www.w3.org/TR/REC-xmlcharsets und 4.3.3 http://www.w3.org/TR/REC-xmlcharencoding sowie in AnhangB http://www.w3.org/TR/REC-xmlCharClasses und AnhangF http://www.w3.org/TR/REC-xmlsec-guessing diskutiert.

Namen von Tags (Attributen, Entities, etc.) Namen (von Elementen oder Attributen etc.) mssen mit einem Buchstaben, einem Unterstrich ``'' oder einem Doppelpunkt beginnen, und kann danach Buchstaben, Ziffern, einen Unterstrich ``'', einen Bindestrich ``-'', einen Punkt ``.'', oder einen Doppelpunkt ``:'' enthalten. ``Combining Characters'' und ``Extenders'' im Sinne des Unicode Standards sind auch erlaubt, nur nicht als erste Zeichen. Der Anhang B des XML Standards enthlt eine lange Liste der Unicode-Bereiche, die als Buchstaben etc.gelten. Die deutschen Umlaute gehren natrlich dazu. Im Gegensatz zu HTML sind Gro- und Kleinschreibung wichtig. A und a sind verschiedene Elemente. Alle Namen, die mit XML in irgend einer Variante bezglich Gro- und Kleinschreibung beginnen, sind fr XML Standards reserviert. Das bedeutet, man kann Namen, die mit ``xml'' beginnen, nicht fr selbst-definierte Tags und Attribute verwenden. Der XML-Standard und der Namespace-Standard legen zum Beispiel eine bestimmte Bedeutung fr die Attribute ``xml:space'', ``xml:lang'' und ``xmlns:...'' fest. Die Verwendung des Doppelpunktes wird durch den Namespace Standard weiter eingeschrnkt (s.u.). D.h.eine Teilmenge der bezglich des XML-Standards erlaubten XML-Dokumente sind auch bezglich des Namespace Standards erlaubt. Z.B.kann es nach dem Namespace Standard maximal einen Doppelpunkt in einem Namen geben, und der Teil vor dem Doppelpunkt mu als Krzel fr einen Namespace deklariert sein. Namen (und andere hufiger verwendete syntaktische Konstrukte) werden in der XML Spezifikation in Abschnitt2.3 definiert: http://www.w3.org/TR/REC-xmlsec-common-syn.

Syntax und Schachtelung von Tags Ein XML Dokument besteht aus Text-Daten und Markup. Die wichtigste Art von Markup sind Tags. Auerdem gibt es noch Entity-Referenzen, Zeichen-Referenzen, Kommentare, Begrenzungen von CDATA Abschnitten, Document Type Deklarationen, und Processing Instructions. Es gibt ffnende, schlieende, und leere Tags. Ein ffnendes Tag besteht aus einem kleiner-Zeichen ``'' (``spitze Klammer auf''), einem Namen wie oben definiert (Name des Element-Typs), optional Attributen (s.u.), und einem grer-Zeichen ``'' (``spitze Klammer zu''). Ein schlieendes Tag besteht aus einem kleiner-Zeichen``'', einem Schrgstrich``/'', einem Namen, und einem grer-Zeichen``''. Ein leeres Tag besteht aus einem kleiner-Zeichen``'', einem Namen, optionalen Attributen, einem Schrgstrich``/'', und einem grer-Zeichen``''. Die Syntax von ffnenden und schlieenden Tags sollte von HTML her bekannt sein (es gibt nur kleine Unterschiede bei den Attributen, s.u.) Im Unterschied zu HTML mu es in XML zu jedem ffnenden Tag ein passendes schlieendes Tag geben. ffnende und schlieende Tags treten also immer in Paaren auf. In HTML werden dagegen Tags wie etwaBR und IMG typischerweise ohne schlieende Tags verwendet. Dazu mu der Browser aber wissen, da diese Tags keinen Inhalt haben knnen. SGML hat recht komplizierte Regeln zur Rekonstruktion weggelassender schlieender Tags. Zum Beispiel mu ein Browser auch wissen, daLI nicht direkt geschachtelt werden kann. Wenn er also ein neues ``List Item'' sieht, wird damit automatisch das vorangegangene beendet. XML soll dagegen auch ohne DTD mit beliebigen Tags syntaktisch analysiert werden knnen. Weil der XML Prozessor also mglicherweise nichts ber die Tags wei, fordert XML, da jedes geffnete Tag explizit wieder geschlossen wird. Weil z.B.``BRBR'' etwas umstndlich aussehen wrde, erlaubt XML als Abkrzung die Verwendung eines ``leeren Tags'': BR. Wenn man mit lteren SGML-Systemen kompatibel sein will, sollte man diese Abkrzung nur fr Elementtypen verwenden, die als EMPTY deklariert sind. Die XML Spezifikation erlaubt es aber ausdrcklich unabhngig von der Definition des Tags, wann immer der Inhalt eines Elementes leer ist. ffnende und schlieende Tags mssen korrekt geschachtelt werden: Wenn ein TagX nach einem TagY geffnet wurde, so muX vor Y wieder geschlossen werden. Zum Beispiel ist ``ABBA'' zulssig, aber ``ABAB'' ist syntaktisch nicht korrekt. Dies funktioniert wie Klammern: ([]) wre eine korrekte Schachtelung, aber ([)] wre inkorrekt. Das heit, das zugehrige schlieende Tag ist ein Tag mit dem gleichen Namen und derart, da gleich viele ffnende und schlieende Tags zwischen den beiden Tags stehen. Man kann die korrekte Schachtelung von Tags mit einem Stack (Keller-Speicher) kontrollieren. Ein Stack ist fr Informatiker eine sehr bekannte Datenstruktur. Es ist eine Liste, bei der man nur an einem Ende etwas anfgen oder entnehmen kann, d.h.sie arbeitet nach dem Last-in, First-out Prinzip (LIFO). Wenn man seinen Keller so vollgerumt hat, da man an die hinteren Sachen nur drankommt, wenn man die vorderen herausrumt, versteht man, warum es Keller-Speicher heit. Oft wird auch ein Stapel von Tellern als Modell genommen, wo man nur oben einen Teller drauflegen oder herunternehmen kann. Fr Kantinen gibt es auch Vorrichtungen mit einer Feder, bei denen immer genau der oberste Teller herausschaut. Die Syntax-Prfung geschieht folgendermaen: Man liest das Dokument von vorne nach hinten. Immer, wenn man ein ffnendes Tag sieht, legt man es oben auf den Stack. Immer, wenn man ein schlieendes Tag liest, nimmt man das oberste Tag vom Stapel, und vergleicht, da die Namen bereinstimmen. Diese beiden Tags gehren dann zusammen. Stimmen die Namen nicht berein, so liegt ein Syntaxfehler vor. Ein Syntaxfehler liegt auch vor, wenn man an ein schlieendes Tag gert, und der Stapel aber schon leer ist. Schlielich liegt ein Syntaxfehler auch dann vor, wenn man am Ende des Dokumentes ist, aber der Stack noch nicht leer ist, es also noch ffnende Tags ohne zugehrige schlieende Tags gibt. Leere Tags sind fr die Syntaxprfung unkritisch, da sie ja automatisch sofort wieder geschlossen werden. bungsaufgabe: Fhren Sie diese Prfung an dem Beispiel durch. Geben Sie jeweils ein Beispiel fr jede der drei Fehlermglichkeiten. Diese Beispiele knnen knstlich sein (mit A, B, etc.). Eine weitere Syntax-Regel von XML ist, da es ein Paar von uersten Tag geben mu, die alle anderen einschlieen. Vor diesem ffnenden Tag und nach dem zugehrigen schlieenden Tag sind keine anderen Tags und kein Text erlaubt. Zum Beispiel wre AABB kein zulssiges XML-Dokument. Dies ist aber keine wesentliche Einschrnkung, weil man immer ein neues ffnendes und schlieendes Tag ganz auen hinzufgen kann: CAABBC. Die grundlegenden Syntax-Regeln fr Tags sind in der XML Spezifikation in Abschnitt2.1 http://www.w3.org/TR/REC-xmlsec-well-formed und Abschnitt3.1 http://www.w3.org/TR/REC-xmlsec-starttags festgelegt.

Elemente, Baum-Darstellung von Dokumenten ffnendes und zugehriges schlieendes Tags und alles, was dazwischen steht, ist ein Element in XML. Entsprechend ist auch jedes leere Tag fr sich ein Element. Diese Bezeichnung wird hier nicht im Sinne der Mengenlehre verwendet. Man knnte vielleicht auch Objekt, Entity, Molekl etc.sagen, aber Element ist das schon bei SGML verwendete Fachwort. In der XML-Spezifikation steht es so: ``Each XML Document contains one or more elements, the boundaries of which are either delimited by start-tags and end-tags, or, for empty elements, by an empty-element tag.'' (Anfang von Kapitel3, http://www.w3.org/TR/REC-xmlsec-logical-struct). Der Name des Tags wird auch Typ des Elementes genannt. Der Inhalt des Elementes ist das, was zwischen ffnendem und schlieendem Tag steht. Leere Tags heien so, weil der Inhalt des durch sie beschriebenen Elementes leer ist. Aus der Spezifikation, Anfang von Kapitel3 http://www.w3.org/TR/REC-xmlsec-logical-struct: ``Each element has a type, identified by name, sometimes called its ``generic identifier'' (GI), and may have a set of attribute specifications....'' Die uersten Tags, die den gesamten Text des Dokumentes und alle anderen Tags einschlieen, entsprechen dem sogenannten Wurzel-Element des Dokumentes. Es wird auch Dokument-Element genannt. Aus der XML-Spezifikation, Abschnitt2.1 http://www.w3.org/TR/REC-xmlsec-well-formed: ``There is exactly one element, called the root, or document element, no part of which appears in the content of any other element. For all other elements, if the start-tag is in the content of another element, the end-tag is in the content of the same element. More simply stated, the elements, delimited by start- and end-tags, nest properly within each other.'' Die Schachtelung der Tags fhrt dazu, da die Elemente als Baum angeordnet werden knnen. Die Wurzel des Baumes ist das Wurzel- oder Dokument-Element (dessen Tags den gesamten Text einschlieen). Jedes Element hat als Kinder die direkt darin geschachtelten Elemente. Zum Beispiel wre bei dem Dokument ``ABBCDDCA'' die Wurzel A, sie htte als Kinder B und C, und C htte als Kind D (Zeichnung an der Tafel). In der Informatik werden verschiedene Varianten von Bumen verwendet. Zum Beispiel kann man einen Baum als endlichen gerichteten Graphen definieren, der zyklenfrei ist, und bei dem es einen Knoten gibt, von dem aus alle anderen Knoten erreichbar sind (der Graph ist daher zusammenhngend). Dieser Knoten, vom dem aus alle anderen erreichbar sind, heit dann Wurzel des Baumes. Wenn es eine Kante von A nach B gibt, heit B Kind von A. In dieser Sprechweise wre die Wurzel also der gemeinsame Urahn aller Knoten des Baumes. Fr unsere Zwecke reicht diese Definition aber noch nicht aus, wir bentigen zustzlich fr jeden Knoten eine lineare Ordnung auf allen seinen Kindern. Zum Beispiel ist es bei Dokumenten ja wichtig, was das erste, zweite, dritte u.s.w.Kapitel ist. Solche Bume werden auch geordnete Bume genannt. bungsaufgabe: Was ist die Baumdarstellung fr das Beispiel-Dokument? Aus Abschnitt2.1 der Spezifikation: http://www.w3.org/TR/REC-xmlsec-well-formed: ``As a consequence of this, for each non-root elementC in the document, there is another elementP in the document such that C is in the content of P, but not in the content of any other element that is in the content ofP. P is referred to as parent ofC, and C as child ofP.'' Wir knnen die Baumdarstellung noch etwas verfeinern, indem wir auch Knoten fr den Text des Dokumentes einfhren. Betrachten wir zum Beispiel das Dokument ``AxxxByyyBCzzzA''. In der Baum-Darstellung ist die Wurzel ein Element-Knoten mit dem Element-Typ ``A''. Dieser Knoten hat vier Kind-Knoten: Einen Text-Knoten mit dem Wert ``xxx'', einen Element-Knoten mit dem Typ ``B'', einen Element-Knoten mit dem Typ ``C'', und einen Text-Knoten mit dem Wert ``zzz''. Der Element-Knoten mit dem Typ ``B'' hat als Kind einen Text-Knoten mit dem Wert ``yyy''. Der Element-Knoten mit dem Typ ``C'' hat keine Kind-Knoten. (Bild an der Tafel, z.B.rechteckige Knoten fr Elemente, Punkt-frmige Knoten fr Text, Name des Element-Typs im Knoten notiert, Wert des Textes unter dem Knoten notiert, pat so zum XPath Datenmodell, s.u.) Wir werden die Baum-Darstellung spter noch weiter verfeinern, insbesondere sieht das XPath Datenmodell wie auch das ``Document Object Model'' (DOM) noch einen extra ``Dokument-Knoten'' als Wurzel vor, dessen Kind dann der Element-Knoten des Dokument-Elementes ist. Dies ist ntig, um z.B.Processing Instructions wie das ``xml-stylesheet'', die vor dem Dokument-Element stehen knnen, im Baum zu erfassen. Man kann zu einem gegebenen Dokument einen Baum aufbauen, indem man wieder einen Stack verwendet. Dieser Stack enthlt nun Knoten des Baumes. Man des Dokument wieder von vorne nach hinten linear durch. Wenn man an ein ffnendes Tag gert, erzeugt man einen Element-Knoten, und ordnet ihn als Kind-Knoten dem derzeit obersten Knoten auf dem Stack zu. (Eine Ausnahme ist das Dokument-Element, das bei dieser Baum-Variante keinen Vater-Knoten hat. Spter wird der Dokument-Knoten diese Rolle spielen, so da dann der Stack niemals leer ist.) Anschlieend legt man den neu erzeugten Knoten auf den Stack. Wenn man ein schlieendes Tag erreicht, kontrolliert man, da der Element-Typ mit dem Typ des obersten Knoten auf dem Stack bereinstimmt, und nimmt diesen Knoten dann vom Stack. Bei einem leeren Tag geht man wie bei einem ffnenden Tag vor, aber legt den Knoten nicht auf den Stack (man wrde ihn ja sozusagen sofort wieder herunternehmen). Fr jeden Abschnitt von Text, der selbst keine weiteren Tags enthlt, erzeugt man einen Text-Knoten, und ordnet ihm dem obersten Knoten des Stacks als Kind-Knoten zu. Auch diese Knoten werden nicht auf den Stack gelegt, da Text-Knoten niemals selbst Kind-Knoten haben knnen. Aufgabe: Fhren Sie diesen Algorithmus fr das Beispiel-Dokument durch.

Entity-Referenzen XML hat eine Art Macro-mechanismus, mit dem Abkrzungen fr XML-Text deklariert werden knnen. Solche Abkrzungen heien Entities und werden spter in einem eigenen Kapitel ausfhrlich behandelt. XML hat fnf vordefinierte Entities: ``lt'' steht fr ein kleiner-Zeichen ``'', ``gt'' steht fr ein grer-Zeichen ``'', ``amp'' steht fr ein kaufmnninsches und-Zeichen (``ampersand'')``'', ``quot'' steht fr ein doppeltes Anfhrungszeichen``'', und ``apos'' steht fr ein einfaches Anfhrungszeichen (Apostroph). Der Ersetzungstext eines Entities wird eingefgt, wenn man ein kaufmnnisches und-Zeichen, den Namen des Entities, und ein Semikolon``;'' schreibt. Zum Beispiel kann man ein kleiner-Zeichen als ``lt'' schreiben. Zur Kompatibilitt mit SGML-Systemen wird empfohlen (``should''), auch diese fnf Entities selbst zu deklarieren. Die Entity-Referenzen wie ``lt'' sollten aus HTML bekannt sein. Im Unterschied zu HTML sind aber nur die oben genannten fnf Entities vordefiniert. Entities fr Umlaute etc.mu man selbst definieren. Entity-Referenzen sind sehr hnlich zu den oben schon erklrten Zeichen-Referenzen: Dort folgt nach dem ``und''-Zeichen aber noch ein Nummer-Zeichen, um anzudeuten, da man ein Zeichen ber seine Nummer im Unicode angibt: Z.B.``169'' (dezimal) oder ``xA9'' (hexadezimal) fr das Copyright-Zeichen``''. Entity-Referenzen werden in der Spezifikation in Abschnitt4.1 behandelt http://www.w3.org/TR/REC-xmlsec-references.

Text, CDATA-Abschnitte Zwischen ffnendem und schlieendem Tag kann (neben weiteren Tags) auch (fast) beliebiger Text stehen. Die einzige Einschrnkung ist, da die Zeichen ``'' und ``'' nicht im Text verwendet werden drfen. Auerdem drfen (s.o) nur graphische (d.h.druckbare) Zeichen des Unicode-Zeichensatzes verwendet werden, plus Leerzeichen, TAB, CR. und LF. Wenn ein XML-Prozessor also ein ``'' sieht, kann er sicher sein, da hier Markup beginnt. Entsprechend signalisiert ein ``'' immer eine Entity-Referenz oder eine Zeichen-Referenz. Wenn man ein ``'' im Text bentigt, kann man dies als Zeichen-Referenz darstellen (60), oder das vordefinierte Entity ``lt'' verwenden: lt. Entsprechend kann ``'' als ``38'' oder als ``amp'' eingegeben werden. Die zweite Mglichkeit ist natrlich bersichtlicher und daher vorzuziehen. Intern ist sie aber nur eine Abkrzung fr die erste Mglichkeit. Wenn man sehr viele dieser speziellen Zeichen bentigt, kann man auch zwischen ``![CDATA['' und ``]]'' beliebigen Text eingeben, auer natrlich ``]]''. Dies entspricht in etwa dem ``verbatim'' in LaTeX, und dem ``PRE'' in HTML. Solche ``![CDATA[''-Abschnitte knnen nicht geschachtelt werden. Den Beginn des geschachtelten Abschnittes wrde XML ignorieren, weil ``'' im inneren ja gerade keine besondere Bedeutung hat, dafr wrde das Ende des geschachtelten Abschnittes dann bereits das Ende des ganzen Abschnittes signalisieren. Aus Kompatibilittsgrnden mit SGML-Systemen wird gefordert, da die Zeichenkette ``]]'' nur als Ende von CDATA-Abschnitten verwendet wird. Man sollte in diesem Fall das ``'' als ``62'' oder ``gt'' eingeben. Ansonsten kann ``]]'' im Text frei verwendet werden. Dies wre fr einen XML-Parser eigentlich nicht ntig, aber die XML-Spezifikation verwendet hier ausdrcklich das Wort ``must''. CDATA-Abschnitte knnen berall im Inhalt von Elementen stehen, wo auch normaler Text stehen kann. In der Spezifikation ist die Produktion fr ``content'' die einzige Verwendung des Nichtterminal-Symbols ``CDSect'', es steht dort gleichberechtigt u.a.mit ``CharData'' (Text). Normalerweise bergibt der XML-Parser den Text der Anwendung genau so, wie er aufgeschrieben ist. Eine Ausnahme ist dabei die Normalisierung der Zeilenenden. In UNIX werden Zeilenenden mit LF markiert, auf Macintosh-Rechnern mit CR, und auf PCs mit der Kombination CR,LF. Der XML-Parser bersetzt PC- und Mac-Zeilenenden in die UNIX-Version. Ein Anwendungsprogramm kann sich also darauf verlassen, da Zeilenenden mit LF (Byte10, x0A) markiert sind. Dies erhht die Portabilitt von XML-Anwendungen und XML-Dateien. Text-Daten werden in Abschnitt2.4 der Spezifikation behandelt http://www.w3.org/TR/REC-xmlsyntax, siehe auch die Produktion43 fr ``content'' in Abschnitt3.1 http://www.w3.org/TR/REC-xmldt-content. CDATA-Abschnitte werden in Abschnitt2.7 der Spezifikation behandelt http://www.w3.org/TR/REC-xmlsec-cdata-sect.

Attribute In Start-Tags und leeren Tags knnen nach dem Element-Typ auch Attribut-Werte fr dieses Element definiert werden, z.B.: PUBL YEAR=1999 MO=11 Attribute sind auch von HTML her bekannt, aber es gibt zwei Unterschiede: Attributwerte mssen immer in Anfhrungszeichen eingeschlossen werden. In HTML knnte zum Beispiel die Jahreszahl auch als ``YEAR=1999'' geschrieben werden. Das ist in XML nicht legal. Die in HTML mgliche Kurzschreibweise fr boolsche Attribute ist ebenfalls ausgeschlossen. Zum Beispiel kann man in HTML schreiben: ``DL compact''. Schaut man in die HTML Spezifikation, findet man, da dieses Attribut nur den Wert ``compact'' haben kann. Das heit, es gibt nur zwei Mglichkeiten: Das Attribut ist fr ein Element definiert, und hat dann den vorgegebenen Wert, oder es ist nicht definiert (das Element hat dieses Attribut nicht). In HTML braucht fr solche Attribute kein Wert angegeben zu werden, es reicht, den Namen des Attributes anzugeben. In XML besteht eine Attribut-Spezifikation immer aus Name und Wert, man mu also DL compact=compact schreiben. (Tatschlich sollen einige Browser damit Schwierigkeiten haben, obwohl es in HTML auch legal ist.) Ein ffnendes Tag besteht also aus dem ``-Zeichen, dem Namen des Element-Typs, null oder mehr Attribut-Angaben, und dem ``''-Zeichen. Zwischen dem Element-Typ und Attribut-Angaben sowie zwischen den einzelnen Attribut-Angaben ist Leerplatz (``white space'', Leerzeichen, Tabulator, oder Zeilenende) erforderlich. Zwischen der letzten Attribut-Angabe und dem ``''-Zeichen ist Leerplatz erlaubt, aber nicht erforderlich. Zwischen dem ``-Zeichen und dem Element-Typ ist Leerplatz nicht erlaubt. Leerplatz mu nicht aus einem einzigen Zeichen bestehen, sondern kann eine beliebige Folge von Leerzeichen, Tabulatoren, und Zeilenenden sein. Jede einzelne Attribut-Angabe besteht aus dem Namen des Attributes, einem Gleichheitszeichen``='', und dem Wert des Attributes. Links und rechts vom Gleichheitszeichen ist Leerplatz erlaubt, aber nicht notwendig. Der Wert des Attributes mu in einfache oder doppelte Anfhrungszeichen eingeschlossen sein, d.h.YEAR='1999' und YEAR=1999 sind beide zulssig. Die beiden Anfhrungszeichen mssen aber bereinstimmen, YEAR=1999' wre ein Syntaxfehler. Verwendet man zur Begrenzung , so kann der Attribut-Wert ' enthalten und umgekehrt. Soll der Attributwert beide Arten von Anfhrungszeichen enthalten, so mu man eine Sorte zum Begrenzen der Zeichenkette verwenden, und diese im Inneren der Zeichenkette dann als apos oder quot schreiben. Attribut-Werte knnen sich ber mehrere Zeilen erstrecken, d.h.es ist nicht erforderlich, da das Anfhrungszeichen in derselben Zeile geschlossen wird. Dafr sind in Attribut-Werten keine kleiner-Zeichen``'' erlaubt (auer als lt). Dadurch kann ein Parser ein eventuell vergessenes Anfhrungszeichen recht einfach finden. Ein ``'' kann in Attributwerten nur fr eine Entity-Referenz verwendet werden. Bei Bedarf mu man es als amp schreiben. Die Reihenfolge von Attribut-Angaben in einem Tag ist unwesentlich. Jedes Element hat eine Menge (ungeordnet) von Attribut-Wert Paaren. Kein Attribut darf zweimal in einem Tag definiert werden.

XML Deklaration Ganz am Anfang eines XML-Dokumentes sollte normalerweise die XML-Deklaration stehen, z.B.: version=1.0 encoding=ISO-8859-1 Wenn Unicode im UTF-8 oder UTF-16 Format verwendet wird, kann die Spezifikation der Zeichencodierung entfallen. Wenn UTF-16 verwendet wird, mu das erste Zeichen der Datei eine spezielle Markierung sein (xFEFF). ASCII ist eine Teilmenge von UTF-8. In diesem Fall ist also keine Codierungs-Deklaration ntig. Man kann die XML-Deklaration weglassen (wenn keine Codierungs-Deklaration ntig ist), aber wenn eine XML-Deklaration vorhanden ist, mu sie mindestens die XML-Version enthalten. Die minimale XML-Deklaration ist also version=1.0 Man beachte, da die Reihenfolge der Klauseln in der XML Deklaration wichtig ist (im Gegensatz zur Reihenfolge von Attributen). Die XML-Deklaration enthlt noch eine dritte Klausel (``Standalone Declaration''), die wie die Zeichencodierungs-Klausel optional ist, und im Zusammenhang mit DTDs unten erklrt wird. Im wesentlichen ist sie nicht ntzlich, weil der Default-Wert ``no'' fast immer richtig ist (und niemals richtig falsch). Die XML Deklaration wird in Abschnitt 2.8 der Spezifikation behandelt http://www.w3.org/TR/REC-xmlsec-prolog-dtd. Siehe auch Abschnitt4.3.1 fr die verwandte Text-Deklaration am Anfang von ``Include-Dateien'' http://www.w3.org/TR/REC-xmlsec-TextDecl. Die Bedeutung der ``Standalone Deklaration'' ist in Abschnitt2.9 erklrt http://www.w3.org/TR/REC-xmlsec-rmd.

Kommentare Kommentare sind Erklrungen zum XML-Dokument, die fr menschliche Leser bestimmt sind (d.h.nicht fr Auswertung durch Programme). Sie sind nicht Bestandteil des eigentlichen Textes des Dokumentes (zhlen also zum Markup, und nicht zu den Text-Daten). Ein XML-Prozessor kann, aber mu nicht, der Anwendung erlauben, auch die Kommentare abzufragen. Der Normalfall sollte wohl sein, da Kommentare vom Programm einfach berlesen werden. Kommentare beginnen mit der Zeichenfolge ``!--'' und enden mit der Zeichenfolge ``--''. Kommentare drfen nicht die Zeichenfolge ``--'' (einen doppelten Anfhrungsstrich) enthalten, dafr sind die ansonsten speziellen Zeichen ``'' und ``'' kein Problem. Manche HTML Browser erlauben dagegen kein Markup in Kommentaren. Zum Beispiel hatte ich einmal einen Kommentar nicht richtig geschlossen, und dennoch wurde alles richtig angezeigt. Es ist etwas unglcklich, da Kommentare in XML so viele Zeichen zum ffnen und Schlieen bentigen. Meist schreiben Programmierer ohnehin weniger Kommentar, als es gut wre. Der Grund ist, da Kommentare in SGML mit ``--'' geffnet und geschlossen werden (was nicht zu viele Zeichen sind), aber nur innerhalb von Markup Deklarationen / Dokument Type Definitionen erlaubt sind (sie sind ja auch hauptschlich dort ntig). In SGML gelangt man mit ``!'' in den Definitionsmodus und verlt ihn wieder mit ``''. HTML und XML Kommentare setzen sich dann aus beidem zusammen. Kommentare sind berall auerhalb von Markup in Dokumenten erlaubt, zustzlich sind sie innerhalb der Dokument Type Definition (die ein groer Block von Markup ist) zwischen den Einzeldeklarationen erlaubt (s.u.). Moderne Programmiersprachen behandeln Kommentare berlicherweise als quivalent zu ``Whitespace'', also wie etwa ein Leerzeichen. XML weicht von diesem Muster ab. Kommentare sind nicht berall erlaubt, wo Leerzeichen erlaubt sind. Auerdem scheint es so, als wre ein Kommentar auch im Inneren eines Wortes erlaubt (?). Auch schreibt die XML-Grammatik genau vor, wo Leerzeichen (whitespace) erlaubt sind. Bei modernen Programmiersprachen gilt die Regel ``zwischen je zwei Token''. Man mu aber sagen, da die XML-Grammatik einstufig ist (keine Trennung lexikalischer und kontextfreier Syntax), so da Token fr XML nicht definiert sind. Wenn man die Spezifikation wrtlich nimmt, wre ein Kommentar auch ganz am Anfang eines Dokumentes erlaubt. Der AnhangF (``Autodetection of Character Encodings'') geht aber davon aus, da die XML-Definition am Anfang stehen mu. Kommentare sind in Abschnitt2.5 der Spezifikation behandelt: http://www.w3.org/TR/REC-xmlsec-comments.

Processing-Instructions Processing-Instruktions sind Hinweise im Dokument fr bestimmte Programme, die das Dokument verarbeiten. Zum Beispiel ist die Angabe des Stylesheets fr XSLT-Prozessoren wichtig: xml-stylesheet type=text/xsl href=notes.xsl Das erste Wort der Processing Instruktion identifiziert das Programm (oder Klasse von Programmen), fr die diese Processing Instruction gedacht ist. Es mu ein Name wie oben definiert sein. Leerplatz zwischen dem Symbol ``?'' und diesem Namen ist verboten. Anderer Leerplatz in der Processing Instruction wird an die Anwendung weitergegeben, ist also mglicherweise signifikant. Obwohl fr Processing-Instruktions die Attribut=Wert Schreibweise relativ blich ist, das Format der Processing-Instruktion nach dem ersten Namen nicht weiter eingeschrnkt. Auch ``'' und ``'' sind legal. Nur ``?'' kann in einer Processing-Instruktion nicht vorkommen, es signalisiert ja gerade ihr Ende. Processing-Instruktions sind berall erlaubt, wo auch Kommentare erlaubt sind. Die XML Spezifikation definiert dies nicht explizit, aber die beiden Nichtterminalsymbole ``Comment'' und ``PI'' treten in der Grammatik immer gemeinsam auf. Processing Instructions sind im Abschnitt2.6 der Spezifikation definiert http://www.w3.org/TR/REC-xmlsec-pi.

Aufgaben Beschaffen Sie sich einige XML-Dateien und schauen Sie sich den Inhalt an (die DTD am Anfang knnen Sie noch nicht verstehen, aber die folgenden Daten schon). xmlTree http://www.xmltree.com/ ist eine Art ``Yahoo!'' fr XML-Dateien im Web. Eine andere Quelle sind Jon Bosak's Shakespeare-Dateien http://sunsite.unc.edu/pub/sun-info/standards/xml/eg/shakespeare.1.10.xml.zip und religse Bcher (inklusive der Bibel) http://sunsite.unc.edu/pub/sun-info/standards/xml/eg/rel200.zip. Schreiben Sie selbst eine kleine XML-Datei und lassen Sie diese Datei von einem Parser auf Wohlgeformtheit prfen (z.B.Komponisten und Stcke, Angestellte und Abteilungen). Internet Explorer5 enthlt einen ``non-validating'' Parser frXML, und ist sogar fr verschiedene UNIX-Betriebssysteme (inklusive Solaris) erhltlich http://www.microsoft.com/windows/ie/download/ie5.htm. Auch Netscape6 und Mozilla sollen XML untersttzen. Es gibt im Web auch einen XML-Validierungs-Service von mehreren Anbietern, zum Beispiel http://www.stg.brown.edu/service/xmlvalid/. Dort mssen Sie nur die URL Ihrer XML-Datei eintragen. Sie knnen aber auch einen Parser lokal installieren, z.B.Apache Xerces http://xml.apache.org/xerces-c/index.html (Xerces ist im wesentlichen eine Bibliothek zum Zugriff auf XML-Daten in eigenen Programmen, aber die beigelegten Beispiel-Programme wie etwa DOMCount knnen zur Syntax-Prfung verwendet werden.) Weitere Verweise finden Sie auf der WWW-Seite dieses Kurses http://www.informatik.uni-giessen.de/staff/brass/xml00/. Entwickeln Sie fnf kurze Beispiele fr nicht-wohlgeformtes XML, die bei dem Parser Ihrer Wahl fnf unterschiedliche Fehlermeldungen erzeugen.