Kompaktkurs XML

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

Kompaktkurs XML, Kapitel 2: ``Well-Formed XML''

Ziel

In diesem und den nächsten beiden Kapiteln wollen wir erklären (definieren), welche Zeichenfolgen syntaktisch korrekte XML-Dokumente sind.
Zum Beispiel ist ein syntaktisch korrektes XML-Dokument:

<?xml version="1.0"?>  <?xml-stylesheet type="text/xsl" href="books_ie.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>

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 Kapitel 7 erläutert wird. Eine Version ohne Stylesheet ist unter [http://www.informatik.uni-giessen.de/staff/brass/xml00/books0.xml] verfügbar. Der Internet Explorer zeigt dann die Baumstruktur (s.u.) an, mit der Möglichkeit, Teilbäume auszublenden oder anzuzeigen.
Wir werden die XML-Syntax hier mit Prosa ``halb-formal'' definieren. Es sei aber ausdrücklich auf die im Web verfügbare XML-Spezifikation verwiesen, die eine kontextfreie Grammatik für XML enthält (plus einige zusätzliche Einschränkungen in Prosa): [http://www.w3.org/TR/REC-xml].

Kontextfreie Grammatiken sind ein wichtiges Werkzeug für Informatiker. Ich wundere mich, wenn ein Buch, das sich ``Referenz`` nennt, nicht die Grammatik für XML enthält. Ich hatte, nachdem ich eine XML Definition in Prosa gelesen hatte, durchaus noch einige Fragen, die sich nur anhand der Grammatik klären ließen. Die Grammatik hat insbesamt 89 Produktionen und die ganze XML Spezifikation hat 36 Seiten.

Zwei Stufen Syntaktischer Korrektheit

Der XML-Standard definiert zwei Stufen syntaktischer Korrektheit.
1. Well-Formed: Alles, was sich ohne ``Document Type Definition'' (Grammatik) prüfen läßt, z.B. die korrekte Klammerstruktur der Tags.
2. Valid: Zusätzlich korrekte Verwendung der Tags gemäß der DTD.
Viele existierende Parser prüfen nur die Wohlgeformtheit. Dies ist zum Beispiel ausreichend, um die DOM-Datenstruktur aufzubauen, und auch für die Darstellung im Browser (zum Beispiel mit XSL).
Die Gültigkeit bezüglich einer Grammatik ist ein zusätzlicher Integritäts-Test.

Zum Beispiel reicht die Wohlgeformtheit aus, ein Stylesheet anzuwenden, aber man wird nicht das gewünschte Ergebnis bekommen, wenn das Eingabedokument nicht der Grammatik genügt, die bei der Entwicklung des Stylesheets angenommen wurde.
Da SGML auch wegen seiner Komplexität im Web nicht akzeptiert wurde, war es wohl sinnvoll, Browser-Herstellern zu ermöglichen, die DTD zu ignorieren.

Tatsächlich muß auch ein non-validating Parser die syntaktische Korrektheit der DTD-Teilmenge im Dokument selbst prüfen, und auch dort definierte Entities, Default-Werte von Attributen etc. berücksichtigen. Es ist also nicht ganz richtig, daß die DTD völlig ignoriert werden kann. Bestimmte syntaktische Komplikationen sind aber nur in externen DTDs erlaubt, die ignoriert werden können. Die Syntax-Regeln, die die DTD vorschreibt, brauchen auch nicht im Dokument geprüft zu werden.
Bei der Entwicklung von DTDs schreibt man häufig zunächst ein Beispiel-Dokument auf. Dies ist auch ohne DTD schon syntaktisch korrektes XML.
Theoretisch könnte 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 unglücklich: Nur wohlgeformtes XML ist nicht automatisch ``invalid''. Nur wenn eine DTD angegeben ist, und das Dokument ihr nicht genügt, könnte man von ``invalid'' sprechen.
In der XML-Spezifikation definiert Abschnitt 5.1 [http://www.w3.org/TR/REC-xml#proc-types] die Anforderungen an ``validating'' und ``non-validating'' XML-Prozessoren.

Die Anforderungen für ``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 erfüllen) und ``validity constraints'' (müssen nur ``valid'' XML-Dokumente erfüllen) unterschieden wird.

Zeichensatz

Ein XML-Dokument ist eine Folge von Zeichen.
Gültige Zeichen sind TAB (tabulator), CR (carriage return), LF (line feed), und die grafischen Zeichen des Unicode Standards und ISO/IEC 10646 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 16 Bits zu repräsentieren [http://www.unicode.org]. Der Unicode Standard stimmt mit der UCS-2/UTF-16 (2 Byte) Variante des ISO/IEC 10646 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 für die XML-Dokumente. Alle XML Prozessoren müssen die UTF-8 und UTF-16 Codierungen des ISO/IEC 10646 Standards verarbeiten können.

UTF-8 arbeitet mit einem Byte für Zeichen mit Nummer bis 127 (#x007F), zwei Byte für Zeichen mit Nummer zwischen 128 und 2047 (#x07FF), drei Byte für Zeichen mit Nummer zwischen 2048 und 65535 (#xFFFF), und vier Bytes für ``Surrogates'' (bisher nicht benutzt). UTF-16 verwendet zwei Byte für jedes Zeichen (und vier Bytes für ``Surrogate Pairs'').

UTF-16 Dokumente müssen mit #xFEFF beginnen, und können so von UTF-8 Dokumenten unterschieden werden. Der XML Standard erklärt im Anhang F (``Autodetection of Character Encodings''), wie verschiedene Codierungen erkannt werden können. Der Standard schreibt vor, daß, sofern nicht UTF-8 oder UTF-16 verwendet werden, die ersten Zeichen <?xml ...?> sein müssen. 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: <?xml version="1.0" encoding="ISO-8859-1"?>. Allerdings kann es sein, daß ein XML-Prozessor diese Codierung nicht kennt und das Dokument zurückweist.
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 großen Gedanken machen.

Wenn man nicht auf einem IBM Großrechner 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 enthält. Zum Beispiel hat das Zeichen ``ä'' in Unicode die Nummer 228 (hexadezimal E4). Es kann als ``ä'' oder ``ä'' notiert werden (wenn man z.B. nur den ASCII Zeichensatz verwendet).

Unicode von den Zeichencodes her auch eine Obermenge von ISO Latin 8859/1. Das nützt allerdings nicht viel, da die UTF-8 Codierung nicht kompatibel ist: Umlaute werden mit zwei Bytes dargestellt, da ihr Code größer als 127 ist. In der Ausgabe erscheinen dann zwei merkwürdige Zeichen für 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 enthält dann die höherwertigen 5 Bits der Unicode-Nummer, das zweite Byte startet mit den Bits ``10'' und enthält dann die niederwertigen 6 Bits der Unicode-Nummer. Die 3-Byte Codierung kann dann alle 16 Bits darstellen: Das erste Byte startet mit ``1110'' gefolgt von den 4 höchstwertigen Bits der Unicode-Nummer, dann folgen zwei Bytes, die beide mit ``10'' beginnen und jeweils 6 Bits enthalten.
Zeichensätze werden in der XML-Spezifikation in den Abschnitten 2.2 [http://www.w3.org/TR/REC-xml#charsets] und 4.3.3 [http://www.w3.org/TR/REC-xml#charencoding] sowie in Anhang B [http://www.w3.org/TR/REC-xml#CharClasses] und Anhang F [http://www.w3.org/TR/REC-xml#sec-guessing] diskutiert.

Namen von Tags (Attributen, Entities, etc.)

Namen (von Elementen oder Attributen etc.) müssen 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 enthält eine lange Liste der Unicode-Bereiche, die als Buchstaben etc. gelten. Die deutschen Umlaute gehören natürlich 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 bezüglich Groß- und Kleinschreibung beginnen, sind für XML Standards reserviert.

Das bedeutet, man kann Namen, die mit ``xml'' beginnen, nicht für selbst-definierte Tags und Attribute verwenden. Der XML-Standard und der Namespace-Standard legen zum Beispiel eine bestimmte Bedeutung für die Attribute ``xml:space'', ``xml:lang'' und ``xmlns:...'' fest.
Die Verwendung des Doppelpunktes wird durch den Namespace Standard weiter eingeschränkt (s.u.).

D.h. eine Teilmenge der bezüglich des XML-Standards erlaubten XML-Dokumente sind auch bezüglich 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 Kürzel für einen Namespace deklariert sein.
Namen (und andere häufiger verwendete syntaktische Konstrukte) werden in der XML Spezifikation in Abschnitt 2.3 definiert: [http://www.w3.org/TR/REC-xml#sec-common-syn].

Syntax und Schachtelung von Tags

Ein XML Dokument besteht aus Text-Daten und Markup. Die wichtigste Art von Markup sind Tags.

Außerdem gibt es noch Entity-Referenzen, Zeichen-Referenzen, Kommentare, Begrenzungen von CDATA Abschnitten, Document Type Deklarationen, und Processing Instructions.
Es gibt öffnende, schließende, 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 größer-Zeichen ``>'' (``spitze Klammer zu'').
Ein schließendes Tag besteht aus einem kleiner-Zeichen ``<'', einem Schrägstrich ``/'', einem Namen, und einem größer-Zeichen ``>''.
Ein leeres Tag besteht aus einem kleiner-Zeichen ``<'', einem Namen, optionalen Attributen, einem Schrägstrich ``/'', und einem größer-Zeichen ``>''.
Die Syntax von öffnenden und schließenden 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 schließendes Tag geben. Öffnende und schließende Tags treten also immer in Paaren auf.

In HTML werden dagegen Tags wie etwa und <IMG> typischerweise ohne schließende Tags verwendet. Dazu muß der Browser aber wissen, daß diese Tags keinen Inhalt haben können. SGML hat recht komplizierte Regeln zur Rekonstruktion weggelassender schließender Tags. Zum Beispiel muß ein Browser auch wissen, daß <LI> 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 können. Weil der XML Prozessor also möglicherweise nichts über die Tags weiß, fordert XML, daß jedes geöffnete Tag explizit wieder geschlossen wird.
Weil z.B. `` '' etwas umständlich aussehen würde, erlaubt XML als Abkürzung die Verwendung eines ``leeren Tags'':  .

Wenn man mit älteren SGML-Systemen kompatibel sein will, sollte man diese Abkürzung nur für Elementtypen verwenden, die als EMPTY deklariert sind. Die XML Spezifikation erlaubt es aber ausdrücklich unabhängig von der Definition des Tags, wann immer der Inhalt eines Elementes leer ist.
Öffnende und schließende Tags müssen korrekt geschachtelt werden: Wenn ein Tag X nach einem Tag Y geöffnet wurde, so muß X vor Y wieder geschlossen werden. Zum Beispiel ist ``<A></A>'' zulässig, aber ``<A></A>'' ist syntaktisch nicht korrekt.

Dies funktioniert wie Klammern: ([]) wäre eine korrekte Schachtelung, aber ([)] wäre inkorrekt.
Das heißt, das zugehörige schließende Tag ist ein Tag mit dem gleichen Namen und derart, daß gleich viele öffnende und schließende Tags zwischen den beiden Tags stehen.
Man kann die korrekte Schachtelung von Tags mit einem Stack (Keller-Speicher) kontrollieren.

Ein Stack ist für Informatiker eine sehr bekannte Datenstruktur. Es ist eine Liste, bei der man nur an einem Ende etwas anfügen oder entnehmen kann, d.h. sie arbeitet nach dem Last-in, First-out Prinzip (LIFO). Wenn man seinen Keller so vollgeräumt hat, daß man an die hinteren Sachen nur drankommt, wenn man die vorderen herausräumt, versteht man, warum es Keller-Speicher heißt. Oft wird auch ein Stapel von Tellern als Modell genommen, wo man nur oben einen Teller drauflegen oder herunternehmen kann. Für Kantinen gibt es auch Vorrichtungen mit einer Feder, bei denen immer genau der oberste Teller herausschaut.
Die Syntax-Prüfung geschieht folgendermaßen: 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 schließendes Tag liest, nimmt man das oberste Tag vom Stapel, und vergleicht, daß die Namen übereinstimmen. Diese beiden Tags gehören dann zusammen. Stimmen die Namen nicht überein, so liegt ein Syntaxfehler vor. Ein Syntaxfehler liegt auch vor, wenn man an ein schließendes Tag gerät, und der Stapel aber schon leer ist. Schließlich 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 zugehörige schließende Tags gibt. Leere Tags sind für die Syntaxprüfung unkritisch, da sie ja automatisch sofort wieder geschlossen werden.

Übungsaufgabe: Führen Sie diese Prüfung an dem Beispiel durch. Geben Sie jeweils ein Beispiel für jede der drei Fehlermöglichkeiten. Diese Beispiele können künstlich sein (mit <A>, , etc.).
Eine weitere Syntax-Regel von XML ist, daß es ein Paar von äußersten Tag geben muß, die alle anderen einschließen. Vor diesem öffnenden Tag und nach dem zugehörigen schließenden Tag sind keine anderen Tags und kein Text erlaubt. Zum Beispiel wäre <A></A> kein zulässiges XML-Dokument. Dies ist aber keine wesentliche Einschränkung, weil man immer ein neues öffnendes und schließendes Tag ganz außen hinzufügen kann: <C><A></A></C>.
Die grundlegenden Syntax-Regeln für Tags sind in der XML Spezifikation in Abschnitt 2.1 [http://www.w3.org/TR/REC-xml#sec-well-formed] und Abschnitt 3.1 [http://www.w3.org/TR/REC-xml#sec-starttags] festgelegt.

Elemente, Baum-Darstellung von Dokumenten

Öffnendes und zugehöriges schließendes Tags und alles, was dazwischen steht, ist ein Element in XML. Entsprechend ist auch jedes leere Tag für sich ein Element.

Diese Bezeichnung wird hier nicht im Sinne der Mengenlehre verwendet. Man könnte vielleicht auch Objekt, Entity, Molekül 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 Kapitel 3, [http://www.w3.org/TR/REC-xml#sec-logical-struct]).
Der Name des Tags wird auch Typ des Elementes genannt. Der Inhalt des Elementes ist das, was zwischen öffnendem und schließendem Tag steht. Leere Tags heißen so, weil der Inhalt des durch sie beschriebenen Elementes leer ist.

Aus der Spezifikation, Anfang von Kapitel 3 [http://www.w3.org/TR/REC-xml#sec-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 äußersten Tags, die den gesamten Text des Dokumentes und alle anderen Tags einschließen, entsprechen dem sogenannten Wurzel-Element des Dokumentes. Es wird auch Dokument-Element genannt.

Aus der XML-Spezifikation, Abschnitt 2.1 [http://www.w3.org/TR/REC-xml#sec-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 führt dazu, daß die Elemente als Baum angeordnet werden können. Die Wurzel des Baumes ist das Wurzel- oder Dokument-Element (dessen Tags den gesamten Text einschließen). Jedes Element hat als Kinder die direkt darin geschachtelten Elemente. Zum Beispiel wäre bei dem Dokument ``<A><C><D></D></C></A>'' die Wurzel A, sie hätte als Kinder B und C, und C hätte als Kind D (Zeichnung an der Tafel).

In der Informatik werden verschiedene Varianten von Bäumen 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 zusammenhängend). Dieser Knoten, vom dem aus alle anderen erreichbar sind, heißt dann Wurzel des Baumes. Wenn es eine Kante von A nach B gibt, heißt B Kind von A. In dieser Sprechweise wäre die Wurzel also der gemeinsame Urahn aller Knoten des Baumes. Für unsere Zwecke reicht diese Definition aber noch nicht aus, wir benötigen zusätzlich für 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 Bäume werden auch geordnete Bäume genannt.

Übungsaufgabe: Was ist die Baumdarstellung für das Beispiel-Dokument?

Aus Abschnitt 2.1 der Spezifikation: [http://www.w3.org/TR/REC-xml#sec-well-formed]: ``As a consequence of this, for each non-root element C in the document, there is another element P 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 of P. P is referred to as parent of C, and C as child of P.''
Wir können die Baumdarstellung noch etwas verfeinern, indem wir auch Knoten für den Text des Dokumentes einführen. Betrachten wir zum Beispiel das Dokument ``<A>xxxyyy<C/>zzz</A>''. 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 für Elemente, Punkt-förmige Knoten für Text, Name des Element-Typs im Knoten notiert, Wert des Textes unter dem Knoten notiert, paßt so zum XPath Datenmodell, s.u.)

Wir werden die Baum-Darstellung später 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 nötig, um z.B. Processing Instructions wie das ``xml-stylesheet'', die vor dem Dokument-Element stehen können, im Baum zu erfassen.
Man kann zu einem gegebenen Dokument einen Baum aufbauen, indem man wieder einen Stack verwendet. Dieser Stack enthält nun Knoten des Baumes. Man des Dokument wieder von vorne nach hinten linear durch. Wenn man an ein öffnendes Tag gerät, 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. Später wird der Dokument-Knoten diese Rolle spielen, so daß dann der Stack niemals leer ist.) Anschließend legt man den neu erzeugten Knoten auf den Stack. Wenn man ein schließendes 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 würde ihn ja sozusagen sofort wieder herunternehmen). Für jeden Abschnitt von Text, der selbst keine weiteren Tags enthält, 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 können.

Aufgabe: Führen Sie diesen Algorithmus für das Beispiel-Dokument durch.

Entity-Referenzen

XML hat eine Art Macro-mechanismus, mit dem Abkürzungen für XML-Text deklariert werden können. Solche Abkürzungen heißen Entities und werden später in einem eigenen Kapitel ausführlich behandelt.
XML hat fünf vordefinierte Entities: ``lt'' steht für ein kleiner-Zeichen ``<'', ``gt'' steht für ein größer-Zeichen ``>'', ``amp'' steht für ein kaufmänninsches und-Zeichen (``ampersand'') ``&'', ``quot'' steht für ein doppeltes Anführungszeichen ``"'', und ``apos'' steht für ein einfaches Anführungszeichen (Apostroph) '.
Der Ersetzungstext eines Entities wird eingefügt, wenn man ein kaufmännisches und-Zeichen, den Namen des Entities, und ein Semikolon ``;'' schreibt. Zum Beispiel kann man ein kleiner-Zeichen als ``<'' schreiben.

Zur Kompatibilität mit SGML-Systemen wird empfohlen (``should''), auch diese fünf Entities selbst zu deklarieren.
Die Entity-Referenzen wie ``<'' sollten aus HTML bekannt sein. Im Unterschied zu HTML sind aber nur die oben genannten fünf Entities vordefiniert. Entities für Umlaute etc. muß man selbst definieren.
Entity-Referenzen sind sehr ähnlich zu den oben schon erklärten 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. ``©'' (dezimal) oder ``©'' (hexadezimal) für das Copyright-Zeichen ``©''.
Entity-Referenzen werden in der Spezifikation in Abschnitt 4.1 behandelt [http://www.w3.org/TR/REC-xml#sec-references].

Text, CDATA-Abschnitte

Zwischen öffnendem und schließendem Tag kann (neben weiteren Tags) auch (fast) beliebiger Text stehen.
Die einzige Einschränkung ist, daß die Zeichen ``<'' und ``&'' nicht im Text verwendet werden dürfen.

Außerdem dürfen (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 benötigt, kann man dies als Zeichen-Referenz darstellen (<), oder das vordefinierte Entity ``lt'' verwenden: <.
Entsprechend kann ``&'' als ``&'' oder als ``&'' eingegeben werden.

Die zweite Möglichkeit ist natürlich übersichtlicher und daher vorzuziehen. Intern ist sie aber nur eine Abkürzung für die erste Möglichkeit.
Wenn man sehr viele dieser speziellen Zeichen benötigt, kann man auch zwischen ``<![CDATA['' und ``]]>'' beliebigen Text eingeben, außer natürlich ``]]>''. Dies entspricht in etwa dem ``verbatim'' in LaTeX, und dem ``<PRE>'' in HTML.
Solche ``<![CDATA[''-Abschnitte können nicht geschachtelt werden.

Den Beginn des geschachtelten Abschnittes würde XML ignorieren, weil ``<'' im inneren ja gerade keine besondere Bedeutung hat, dafür würde das Ende des geschachtelten Abschnittes dann bereits das Ende des ganzen Abschnittes signalisieren.
Aus Kompatibilitätsgründen mit SGML-Systemen wird gefordert, daß die Zeichenkette ``]]>'' nur als Ende von CDATA-Abschnitten verwendet wird. Man sollte in diesem Fall das ``>'' als ``>'' oder ``>'' eingeben. Ansonsten kann ``]]>'' im Text frei verwendet werden.

Dies wäre für einen XML-Parser eigentlich nicht nötig, aber die XML-Spezifikation verwendet hier ausdrücklich das Wort ``must''.
CDATA-Abschnitte können überall im Inhalt von Elementen stehen, wo auch normaler Text stehen kann.

In der Spezifikation ist die Produktion für ``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 (Byte 10, x0A) markiert sind. Dies erhöht die Portabilität von XML-Anwendungen und XML-Dateien.
Text-Daten werden in Abschnitt 2.4 der Spezifikation behandelt [http://www.w3.org/TR/REC-xml#syntax], siehe auch die Produktion 43 für ``content'' in Abschnitt 3.1 [http://www.w3.org/TR/REC-xml#dt-content]. CDATA-Abschnitte werden in Abschnitt 2.7 der Spezifikation behandelt [http://www.w3.org/TR/REC-xml#sec-cdata-sect].

Attribute

In Start-Tags und leeren Tags können nach dem Element-Typ auch Attribut-Werte für dieses Element definiert werden, z.B.:

<PUBL YEAR="1999" MO="11">
Attribute sind auch von HTML her bekannt, aber es gibt zwei Unterschiede:
1. Attributwerte müssen immer in Anführungszeichen eingeschlossen werden.
 
 In HTML könnte zum Beispiel die Jahreszahl auch als ``YEAR=1999'' geschrieben werden. Das ist in XML nicht legal.
2. Die in HTML mögliche Kurzschreibweise für 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 heißt, es gibt nur zwei Möglichkeiten: Das Attribut ist für ein Element definiert, und hat dann den vorgegebenen Wert, oder es ist nicht definiert (das Element hat dieses Attribut nicht). In HTML braucht für 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. (Tatsächlich 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 Anführungszeichen eingeschlossen sein, d.h. YEAR='1999' und YEAR="1999" sind beide zulässig.

Die beiden Anführungszeichen müssen aber übereinstimmen, YEAR="1999' wäre ein Syntaxfehler. Verwendet man zur Begrenzung ", so kann der Attribut-Wert ' enthalten und umgekehrt. Soll der Attributwert beide Arten von Anführungszeichen enthalten, so muß man eine Sorte zum Begrenzen der Zeichenkette verwenden, und diese im Inneren der Zeichenkette dann als ' oder " schreiben.
Attribut-Werte können sich über mehrere Zeilen erstrecken, d.h. es ist nicht erforderlich, daß das Anführungszeichen in derselben Zeile geschlossen wird.
Dafür sind in Attribut-Werten keine kleiner-Zeichen ``<'' erlaubt (außer als <).

Dadurch kann ein Parser ein eventuell vergessenes Anführungszeichen recht einfach finden.
Ein ``&'' kann in Attributwerten nur für eine Entity-Referenz verwendet werden.

Bei Bedarf muß man es als & 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.:

<?xml 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 nötig.

Man kann die XML-Deklaration weglassen (wenn keine Codierungs-Deklaration nötig ist), aber wenn eine XML-Deklaration vorhanden ist, muß sie mindestens die XML-Version enthalten. Die minimale XML-Deklaration ist also <?xml 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 enthält noch eine dritte Klausel (``Standalone Declaration''), die wie die Zeichencodierungs-Klausel optional ist, und im Zusammenhang mit DTDs unten erklärt wird.

Im wesentlichen ist sie nicht nützlich, 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-xml#sec-prolog-dtd]. Siehe auch Abschnitt 4.3.1 für die verwandte Text-Deklaration am Anfang von ``Include-Dateien'' [http://www.w3.org/TR/REC-xml#sec-TextDecl]. Die Bedeutung der ``Standalone Deklaration'' ist in Abschnitt 2.9 erklärt [http://www.w3.org/TR/REC-xml#sec-rmd].

Kommentare

Kommentare sind Erklärungen zum XML-Dokument, die für menschliche Leser bestimmt sind (d.h. nicht für Auswertung durch Programme). Sie sind nicht Bestandteil des eigentlichen Textes des Dokumentes (zählen 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 ``''. Kommentare dürfen nicht die Zeichenfolge ``--'' (einen doppelten Anführungsstrich) enthalten, dafür 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 unglücklich, daß Kommentare in XML so viele Zeichen zum Öffnen und Schließen benötigen. Meist schreiben Programmierer ohnehin weniger Kommentar, als es gut wäre. Der Grund ist, daß Kommentare in SGML mit ``--'' geöffnet und geschlossen werden (was nicht zu viele Zeichen sind), aber nur innerhalb von Markup Deklarationen / Dokument Type Definitionen erlaubt sind (sie sind ja auch hauptsächlich dort nötig). In SGML gelangt man mit ``<!'' in den Definitionsmodus und verläßt ihn wieder mit ``>''. HTML und XML Kommentare setzen sich dann aus beidem zusammen.
Kommentare sind überall außerhalb von Markup in Dokumenten erlaubt, zusätzlich sind sie innerhalb der Dokument Type Definition (die ein großer 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. Außerdem scheint es so, als wäre 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 für XML nicht definiert sind.

Wenn man die Spezifikation wörtlich nimmt, wäre ein Kommentar auch ganz am Anfang eines Dokumentes erlaubt. Der Anhang F (``Autodetection of Character Encodings'') geht aber davon aus, daß die XML-Definition am Anfang stehen muß.
Kommentare sind in Abschnitt 2.5 der Spezifikation behandelt: [http://www.w3.org/TR/REC-xml#sec-comments].

Processing-Instructions

Processing-Instruktions sind Hinweise im Dokument für bestimmte Programme, die das Dokument verarbeiten.
Zum Beispiel ist die Angabe des Stylesheets für XSLT-Prozessoren wichtig:

<?xml-stylesheet type="text/xsl" href="notes.xsl"?>
Das erste Wort der Processing Instruktion identifiziert das Programm (oder Klasse von Programmen), für 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 möglicherweise signifikant.
Obwohl für Processing-Instruktions die Attribut=Wert Schreibweise relativ üblich ist, das Format der Processing-Instruktion nach dem ersten Namen nicht weiter eingeschränkt. 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 Abschnitt 2.6 der Spezifikation definiert [http://www.w3.org/TR/REC-xml#sec-pi].

Aufgaben

Beschaffen Sie sich einige XML-Dateien und schauen Sie sich den Inhalt an (die DTD am Anfang können Sie noch nicht verstehen, aber die folgenden Daten schon).

xmlTree [http://www.xmltree.com/] ist eine Art ``Yahoo!'' für 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 religöse Bücher (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 prüfen (z.B. Komponisten und Stücke, Angestellte und Abteilungen).

Internet Explorer 5 enthält einen ``non-validating'' Parser für XML, und ist sogar für verschiedene UNIX-Betriebssysteme (inklusive Solaris) erhältlich [http://www.microsoft.com/windows/ie/download/ie5.htm]. Auch Netscape 6 und Mozilla sollen XML unterstützen. Es gibt im Web auch einen XML-Validierungs-Service von mehreren Anbietern, zum Beispiel [http://www.stg.brown.edu/service/xmlvalid/]. Dort müssen Sie nur die URL Ihrer XML-Datei eintragen. Sie können 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 können zur Syntax-Prüfung verwendet werden.) Weitere Verweise finden Sie auf der WWW-Seite dieses Kurses [http://www.informatik.uni-giessen.de/staff/brass/xml00/].
Entwickeln Sie fünf kurze Beispiele für nicht-wohlgeformtes XML, die bei dem Parser Ihrer Wahl fünf unterschiedliche Fehlermeldungen erzeugen.

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