XML-Dokumente erstellen

(Auszug aus "Python & XML" von Christopher A. Jones & Fred L. Drake, Jr.)

Dokumente sind das Herzstück von XML. Jede Anhäufung brauchbaren XML-Texts wird als Dokument dargestellt und oft in einer Datei gespeichert. Eines der allerersten Dinge, die Sie verstehen müssen, um XML zu benutzen, ist, wie man ein wohlgeformtes Dokument erzeugt. In diesem Abschnitt untersuchen wir die syntaktischen Komponenten eines Dokuments, beginnend bei den einzelnen Zeichen, und betrachten, wie diese gesehen werden, wenn größere syntaktische Konstrukte aufgebaut werden. Dann sehen wir uns die Konstrukte an, die in der XML-Empfehlung für alle Dokumente definiert sind.

Zeichen in XML-Dokumenten

Die XML-Spezifikation definiert ein Zeichen als »eine atomare Texteinheit, wie sie in ISO/IEC 10646 definiert wird«. (Man erinnere sich: Hinter ISO/IEC 10646 verbirgt sich die geläufigere Bezeichnung Unicode.) Dies ist natürlich genau das, was Sie auf einer Party sagen sollten, wenn Sie gefragt werden. Eines der Ziele von Standardisierungen und von XML ist es, Dokumente auf Plattformen weltweit leicht verständlich zu machen. In diesem Fall können einfache Dinge wie ASCII-Zeichen ziemlich kompliziert werden.

Unabhängig davon sagt die Spezifikation aus, daß »Tabulator, Carriage Return und Zeilenvorschub« genauso zu den erlaubten Zeichen gehören wie jene der zuvor genannten Unicode-Spezifikation. Sollten Sie einen XML-Parser schreiben müssen, wäre für Sie das Thema Zeichen und Standardisierung extrem wichtig. Für den Rest von uns reicht es normalerweise, einen XML-Parser auszusuchen, der es einfach hinbekommt.

Sie können die in einem XML-Dokument verwendete Zeichencodierung in der optionalen XML-Deklaration angeben:

 <?xml version="1.0" encoding="UTF-8"?> 

Bei einem externen Entity, das für sich genommen kein Dokument ist, wird eine Variante der XML-Deklaration verwendet, die Codierungsdeklaration genannt wird:

 <?xml encoding="UTF-8"?> 

Weitere Informationen über die XML-Deklaration werden im Abschnitt Der Dokument-Prolog vorgestellt. Schauen wir uns vorher einige der meistverwendeten Zeichensätze und Codierungen an. (Einen Zeichensatz, der auf Unicode abgebildet werden kann, kann man als Unicode-Codierung betrachten, selbst wenn er nicht direkt alles unterstützt, was in Unicode definiert ist.)

Der ASCII-Zeichensatz

ASCII, der American Standard Code for Information Interchange, ist ein 7-Bit-Textformat (d. h. ein Zeichen besteht aus einer Folge von sieben Einsen und Nullen). ASCII wird sozusagen von jedem heute benutzten Rechner verstanden. Unicode erweitert ASCII, sodass die ersten 128 Zeichen von Unicode mit den ersten 128 Zeichen von ASCII übereinstimmen.

Der Zeichensatz ISO-8859-1

Der Zeichensatz ISO-8859-1 ist auch unter dem Namen Latin-1 bekannt. ISO-8859-1 ist sehr weit verbreitet, da er die meisten (aber nicht alle) westeuropäischen Sprachen unterstützt. Aus Kompatibilitätsgründen sind die ersten 256 Zeichen von Unicode identisch mit ISO-8859-1. Die ersten 128 Zeichen von ISO-8859-1 sind identisch zu ASCII. Die zweiten 128 sind eine Mischung aus Steuerzeichen, speziellen Zeichen und diakritischen Zeichen. ISO-8859-1 wurde vom DEC Multinational Character Set inspiriert, aber es gibt einige Unterschiede. Es gibt auch weitere Zeichensätze unter ISO-8859-X, die zusätzliche Sprachen und Zeichen unterstützen.

UTF-8-Codierung

UTF-8, das Universal Transformation Format, 8-Bit, wird in IETF RFC 2279 von F. Yergeau dokumentiert. UTF-8 ist die populärste komplette Unicode-Codierung.

UTF-8 erweitert ASCII zu einem gewissen Grade. Die ersten 128 Positionen von UTF-8 werden transparent auf ihre ASCII-Entsprechungen codiert. Da Unicode über zwei Milliarden Zeichen unterstützt (d. h. wesentlich mehr als 128), braucht es einiges an Codierung, um es in einen Strom diskreter 8-Bit-Bytes zu pressen. UTF-8 löst dieses Problem, indem jedes Unicode-Zeichen mit einer eindeutigen Bytefolge dargestellt wird. In einem UTF-8-Strom besetzen ASCII-Zeichen nur ein Byte in dem Strom, während alle anderen Zeichen durch zwei oder mehr Bytes im Strom dargestellt werden. Ihre XML-Deklaration erscheint in UTF-8 wie folgt:

 <?xml version="1.0" encoding="UTF-8"?> 

Detaillierte Informationen zum Umgang mit der UTF-8-Codierung befinden sich im RFC.

Text, Zeichendaten und Auszeichnungen

Die Spezifikation besagt: »Text besteht aus vermischten Zeichendaten und Auszeichnungen.« Der wesentliche Punkt ist, daß jedes Zeichen in einem XML-Dokument entweder zu den Zeichendaten gehört (der eigentlich interessante Informationsgehalt, z. B. eine Adresse oder eine Mengenangabe) oder Teil der Auszeichnung (oder des Markups) ist (das sind alle speziellen Zeichen, die man für Start- und End-Tags, Entities, Kommentare, CDATA-Begrenzungen, DTDs, Prozessierungsanweisungen und Deklarationen braucht). Alle Zeichen bilden zusammen den Text.

Zeichendaten in Elementinhalten sind »alle Zeichen-Strings, die keine Startbegrenzungen irgendwelcher Auszeichnungen enthalten«. Offensichtlich ist es wichtig, den Unterschied zwischen beiden zu kennen, da es die Auszeichnungen sind, die es unseren Programmen ermöglichen, die Zeichendaten korrekt zu interpretieren.

Alle Auszeichnungen beginnen mit einem von zwei Zeichen: das Kleiner-als-Zeichen (<) und das Kaufmanns-Und (&). Alle Auszeichungen, die mit dem Kleiner-als-Zeichen beginnen, enden mit dem Größer-als-Zeichen (>), und Auszeichnungen, die mit einem Kaufmanns-Und beginnen, enden mit einem Semikolon (;). Dies sind meistens die einzigen speziellen Zeichen, die Sie kennen müssen. In einigen Situationen verlangen einfache (') und doppelte (") Anführungszeichen besondere Beachtung. Das bedeutet nicht, daß Ihre Dokumente und Daten diese Zeichen nicht enthalten dürfen, sondern nur, daß sie eine besondere Codierung im XML-Text erfordern. Jedes Unicode-Zeichen darf in den Zeichendaten vorkommen.

Eine Folge davon ist, daß Sie einige spezielle Zeichen wie das Kaufmanns-Und (&) oder spitze Klammern (<, >) nicht direkt als solche in Ihrem Text benutzen können. Folgendes würde einen XML-Prozessor z. B. verwirren:

 <question>Ist 5 < 7 ≤ 9?</question> 

Der Text des Elements question enthält Zeichen, die in der Spezifikation nicht erlaubt sind. Das < muß eine neue Auszeichnungskomponente einleiten, so daß das anschließende Leerzeichen als Syntaxfehler interpretiert wird. Das Kleiner-als-Zeichen wird für den Beginn einer Reihe von Auszeichnungskonstrukten benutzt, von denen Start- und End-Tags die geläufigsten sind. Das Kaufmanns-Und wird zur Auszeichnung von Entity-Referenzen benutzt.

Um diese besonderen Zeichen in Ihrem XML-Dokument benutzen zu können, müssen Sie sie mit Entities oder Zeichenreferenzen codieren. Um das Beispiel in korrektes XML zu verwandeln, müssen wir folgendes schreiben:

 <question>Ist 5 &lt; 7 &#x2263; 9?</question> 

Entity-Referenzen werden später in diesem Kapitel erläutert, obwohl sie vielen, die bereits mit HTML gearbeitet haben, schon bekannt vorkommen werden, da z. B. &apos; ('), &quot; ("), &lt; (<) und &gt; (>) auch dazugehören. XML erlaubt Ihnen auch, Ihre eigenen Entities zu definieren, die auch mehr als ein Zeichen enthalten können, aber diese vier werden in der XML-Spezifikation definiert und müssen nicht gesondert für Ihre Dokumente definiert werden. Zeichenreferenzen sind insofern etwas anders, als sie einzelne Unicode-Zeichen spezifizieren, ohne mnemonische Bezeichner dafür zu verwenden. Eine Zeichenreferenz, die Sie vielleicht schon in HTML gesehen haben, könnte z. B. &#174; sein (®, das Symbol für registrierte Warenzeichen). In XML darf der numerische Teil der Referenz auch in hexadezimalen Ziffern angegeben werden, wenn der Buchstabe x zwischen dem Doppelkreuz und der ersten Ziffer eingefügt wird. Die Referenz &#xAE; bezieht sich also auf das Symbol eines registrierten Warenzeichens. Zeichenreferenzen können nicht von Autoren definiert werden, und sie beziehen sich immer mit jener Ordnungszahl auf Unicode-Zeichen, die ihnen in der Unicode-Spezifikation zugewiesen wurden.

Namen

Die XML-Spezifikation definiert mehrere kleine lexikalische Details, aber eines der vielleicht wichtigsten sind Namen. Namen sind Token, die sich aus einer Kombination von erlaubten Zeichen, darunter Buchstaben, Ziffern, Unterstriche, Bindestriche oder Doppelpunkte, zusammensetzen. Das erste Zeichen eines Namens darf keine Ziffer sein. Namens-Token werden benutzt, um alles zu benennen, was in XML einen Namen braucht, inklusive Elementtypen, Attribute und Entities. Einige Namen können nicht in alltäglichen XML-Auszeichnungen verwendet werden. Erstens sind Namen, die mit dem String xml beginnen (in beliebiger Groß-/Kleinschreibung), »reserviert für die Standardisierung [der XML-Spezifikation] oder für zukünftige Versionen dieser Spezifikation«. Zweitens müssen Sie in Ihren Elementnamen Doppelpunkte (:) vermeiden, da sie die Grundlage von XML-Namensräumen darstellen (eine Methode, Elementnamen mit Präfix-Token zu versehen, um ihnen einen Domain-Kontext zuzuordnen). Obwohl die XML 1.0-Spezifikation Doppelpunkte in Element- und Attributnamen erlaubt, weisen ihnen die neueren Namensraum-Spezifikationen eine besondere syntaktische Bedeutung zu, die deren Einsatz einschränkt. Mit anderen Worten: Wenn Sie eine gesamte Klasse von speziell auf Bücher bezogenen Elementen definieren, z. B. bookTitle oder bookAuthor, ist es besser, Groß-/Kleinschreibung, Bindestriche oder Unterstriche zu verwenden, um die Wörter voneinander zu trennen (z. B. book_Title, book-Title oder bookTitle), statt Doppelpunkte wie in book:Title zu benutzen. Ein Ausdruck wie book:Title verführt XML-Prozessoren zu der Annahme, daß Sie sich auf ein Element namens Title in dem Namensraum-URI beziehen, der dem lokalen Element book angehängt ist. Es kann natürlich sein, daß Namensräume für Ihre Anwendung genau das richtige sind, wobei Sie sich dann die Zeit nehmen sollten, die Namensraum-Spezifikation sehr aufmerksam zu lesen und jene Namensräume zu definieren, die gebraucht werden.

Leerraum in Zeichendaten

Bei der Arbeit mit XML-basierten Auszeichnungssprachen kann es schwer sein zu wissen, wie man Leerraum behandelt. In vielen Anwendungen kann man Leerraum einfach wie weitere gewöhnliche Zeichendaten behandeln, während dies in anderen nicht ausreicht. Das Problem tritt meist dann auf, wenn die Darstellung dem Benutzer gegenüber von der Anwendung gesteuert wird. Obwohl die XML-Spezifikation das Problem nicht zu lösen versucht, bietet sie eine Möglichkeit, Hinweise für Werkzeuge und Anwendungen einzubauen, daß der Leerraum in einem bestimmten Element als solcher beibehalten und nicht als dehnbarer Raum behandelt werden soll.

Die einfachste Methode, das Problem darzustellen, ist, sich anzuschauen, wie Programm-Quellcode in HTML meistens dargestellt wird. Die meisten HTML-Autoren betten Quellcode in einem pre-Element ein:

<pre>
def hello( ):
   print "Hallo, Welt!"
</pre>

Dies ist gewiß die einfachste Art, um Quellcode in HTML darzustellen. Betrachten Sie nun, was passiert, wenn wir statt eines pre -Elements einen Absatz, d. h. ein p -Element, benutzen:

<p>
def hello( ):
   print "Hallo, Welt!"
</p>

Das hat in den meisten Webbrowsern einen ganz anderen Effekt zur Folge, wobei normalerweise das gesamte Programm in einer einzigen Zeile dargestellt wird, mit nur einem Leerzeichen zwischen zwei Wörtern, obwohl das Beispiel mehrere Zeilen und mehrere Leerzeichen nebeneinander enthält.

Die Lösung sieht einfach aus, jedenfalls für HTML. Man benutzt einfach ein pre -Element, wenn man Leerraum beibehalten möchte. Diese offensichtliche Lösung hat leider ein ebenso offensichtliches Problem – sie funktioniert nur für HTML, aber nicht für beliebige XML-basierte Auszeichnungssprachen. Man braucht eine Lösung wie die folgende, die auch für Nicht-HTML-Dokumente funktioniert:

<Poem>
   Ode to a node,
   Nested beneath its tree,
   Snug as a bug in its XML rug
   Dreaming of the W3C.
</Poem>

Woher soll ein XML-Werkzeug wissen, daß die Zeilenenden und die Art der Darstellung des Gedichtes von Bedeutung sind?

Die XML-Spezifikation definiert ein Attribut namens xml:space, das Sie einem Element anfügen können, um der Anwendung mitzuteilen, daß Leerraum beibehalten werden soll. Es ist Aufgabe der Client-Anwendung, gemäß dieser Information zu handeln und den Leerraum tatsächlich zu bewahren, wenn sie Daten verarbeitet oder formatiert. Ein typischer XML-Parser gibt den Leerraum aus dem Dokument an die Anwendung weiter, unabhängig davon, ob er das Attribut xml:space gesehen hat (im Dokument oder im Schema). Eine Anwendung kann das Attribut benutzen, um zu entscheiden, welche Manipulationen sie auf dem Dokumentinhalt durchführt.

Der Wert des Attributs xml:space kann entweder default oder preserve sein. Bei default darf die Anwendung den Leerraum behandeln, wie auch immer sie das normalerweise täte; die XML-Spezifikation beschränkt hier in keinster Weise, was mit dem Leerraum passiert. Lautet der Wert jedoch preserve, so wird erwartet, daß die Anwendung den Leerraum des Elements respektiert, für das das Attribut gilt, sowie für alle weiteren Kindelemente, bis sie ein Kind findet, das einen Wert für xml:space definiert. Ab dann hat der Wert von xml:space jenes Kindes Vorrang für das Kind selbst sowie für seine weiteren Abkömmlinge.

Das Attribut xml:space kann auf mehrere verschiedene Arten benutzt werden. Die erste ist, es einfach in der Dokument-Instanz einzufügen, was für wohlgeformtes XML ausreicht. Damit wird die erste Zeile unseres Gedichtes zu:

 <Poem xml:space="preserve"> 

Während dies bei kleinen Mengen von XML-Text ganz vernünftig erscheint, zeigt sich, daß es bei großen Mengen von Dokumenten, die von Menschen editiert werden, nicht mehr funktioniert. Denken Sie einmal nach, wie HTML aussähe, wenn wir immer ein spezielles Attribut verwenden müßten, um den Effekt des pre-Elements zu erhalten! Aus diesem Grund wird das Attribut xml:space meistens im Dokumentschema eingefügt. In einer DTD würden wir etwa folgendes schreiben:

<!ATTLIST Poem xml:space (default|preserve) 'preserve'> 

Deklarationen von Attributlisten werden später im Abschnitt Attributdeklarationen detaillierter erläutert.

Praktisch gesehen, gilt für die meisten Anwendungen, die XML parsen, daß sie aus den Elementnamen schließen, was mit den darin enthaltenen Zeichendaten zu tun ist. Beim Parsen eines in XML formatierten Buchtextes könnten Sie z. B. auf ein code-Element stoßen, das Ihnen sagt, der Leerraum in diesem Abschnitt sollte bewahrt werden. Schauen Sie jedoch genauer hin, gibt der Dokumenttyp oft an, daß xml:space eine Voreinstellung von preserve für diese Elemente hat.

Behandlung von Zeilenenden

Die Spezifikation ist sehr direkt, was die Behandlung von Zeilenenden angeht. Ein XML-Parser muß Zeichen mit normalisierten Zeilenenden an eine Anwendung weitergeben. Das heißt, alle Kombinationen der hexadezimalen Zeichen 0x0D und 0x0A oder einzelne 0x0D-Zeichen ohne anschließendes 0x0A werden in ein einzelnes 0x0A-Zeichen konvertiert. Für die weniger »Hexadezimalen« unter uns: Das bedeutet, daß typische Formatierungscodes wie z. B. \r\n und \r zu \n konvertiert werden. Und für jene von Ihnen, die noch nie diese seltsamen Schrägstrichzeichen benutzt haben: Es bedeutet, daß Text von Plattformen, die ihre Zeilen normalerweise mit Carriage Return- und Zeilenvorschub-Zeichen beenden (z. B. Windows), so konvertiert wird, daß nur noch Zeilenvorschub-Zeichen verwendet werden.

Sprachidentifikation

Die Spezifikation enthält ein Attribut namens xml:lang, das in Dokumenten benutzt werden kann, um die darin verwendete Sprache anzugeben. Wieder gilt, daß dieses Attribut in gültigen Dokumenten angegeben werden muß, ganz ähnlich wie xml:space. Die Werte, die bei diesem Attribut benutzt werden dürfen, sind in IETF RFC 1766 oder einer späteren Version davon definiert. Die meisten Sprachcodes haben zwei Buchstaben, z. B. en für Englisch, aber Dialekte können mit einem Unterstrich und zwei weiteren Buchstaben angegeben werden. Amerikanisches Englisch kann daher mit en_US und das britische Englisch kann mit en_GB angegeben werden.

Der Dokument-Prolog

Ein XML-Dokument enthält einen Prolog, der alles enthält, was vor dem einzigen Element steht, das den Dokumentinhalt ausmacht. Der Prolog besteht aus einer optionalen Deklaration, XML-Deklaration genannt, gefolgt von einer optionalen Dokumenttyp-Deklaration, gefolgt von einer beliebigen Anzahl (inklusive null!) von Kommentaren und Verarbeitungsanweisungen. Der Prolog darf damit komplett leer sein, enthält aber oftmals die XML-Deklaration als Zeichen guten Willens und einer guten Form. Die Dokumenttyp-Deklaration wird benötigt, wenn das Dokument einer DTD entsprechen soll.

Die XML-Deklaration sieht sehr wie eine Verarbeitungsanweisung aus, ist aber wegen ihres speziellen Zwecks doch ein wenig verschieden davon. Da XML verlangt, daß alle Dokumente in Unicode sein müssen – aber nicht die Codierung der Unicode-Zeichen auf Bytes jenes Datenstroms einschränkt, der das Dokument enthält –, muß es einen Weg geben, diese Codierung zu bestimmen. Einige Codierungen können anhand der ersten Bytes des Datenstroms erkannt werden. Eine Anzahl spezifischer Regeln zur Bestimmung der Codierung aus den ersten Bytes des Datenstroms ist Teil der XML-Empfehlung. Bei vielen Codierungen ist das jedoch nicht möglich. Die XML-Spezifikation besagt, daß in jenen Fällen, in denen die Codierung nicht vorab bekannt ist (z. B. wenn die Codierung im Header einer HTTP-Antwort zurückgegeben wird), das Dokument in UTF-8 codiert sein oder eine XML-Deklaration enthalten muß, die diese Codierung angibt. Die Deklaration enthält immer die Version der XML-Spezifikation, zu der das Dokument konform ist (bisher wurde nur XML 1.0 definiert). Eine typische XML-Deklaration könnte wie folgt aussehen:

 <?xml version="1.0" encoding="iso-8859-1"?> 

Dies besagt, daß das Dokument im Zeichensatz ISO 8859-1, besser bekannt unter Latin-1, codiert ist. Es ist absolut zulässig, die Codierung in der Deklaration auch wegzulassen, so daß die minimale Deklaration so aussieht:

 <?xml version="1.0"?> 

Bestimmt kann man dies schon auf Kaffeetassen lesen.

Nach der XML-Deklaration kann eine Dokumenttyp-Deklaration folgen. Man beachte, daß sie verschieden von der Dokumenttyp-Definition ist, obwohl die ersten beiden Wörter und offensichtlich auch die Abkürzungen identisch sind. Um einige Verwirrung zu vermeiden, wird die Abkürzung »DTD« nie für die Deklaration benutzt. Sie wird normalerweise als »DOCTYPE-Deklaration« bezeichnet. Falls angegeben, gibt diese Deklaration den Namen des Dokumentelements an, darf aber auch interne und externe Komponenten der DTD angeben. Sehen wir uns die einfachste Form dieser Deklaration an:

 <!DOCTYPE book> 

Das sagt uns, daß das Dokumentelement vom Typ book ist, und sonst nichts; das allein ist nicht sehr nützlich. Tatsächlich gibt es bei dieser Deklaration zwei zusätzliche Komponenten, von denen beide optional sind, aber eine oder beide angegeben werden müssen, damit die Deklaration einen Sinn ergibt. Das folgende Beispiel enthält beide dieser Komponenten:

<!DOCTYPE book SYSTEM "http://xml.example.com/dtds/book.dtd" [
   <!ENTITY myCompany "Super Mega Ultra Corporation">
  ]>

Hierbei ist die Angabe einer externen Teilmenge der DTD enthalten (der String SYSTEM sowie der in Anführungszeichen stehende String) und eine interne Teilmenge in eckigen Klammern.

Wenn die Dokumenttyp-Deklaration existiert, muß der Name des Dokumenttyps mit dem des Wurzelelements übereinstimmen. Wenn Sie Ihren Dokumenttyp als <!DOCTYPE Tool [...]> deklarieren, muß Ihr Wurzelelement Tool lauten. Außerdem müssen alle in der DTD angegebenen Beziehungen hinsichtlich Verschachtelung, Zeichendaten und Attribute bei dem Dokument erzwungen werden, falls es den Gültigkeitstest bestehen soll.

Wenn Sie sowohl interne als auch externe Teilmengen verwenden, gilt, daß die interne Teilmenge Vorrang vor der externen hat. Das heißt, daß die Regeln in der DTD innerhalb Ihres XML-Dokuments Vorrang haben vor jenen Regeln für das gleiche Konstrukt in einer externen DTD-Teilmenge.

Start-, End- und leere Element-Tags

Der Name eines Elements teilt seinen Typ mit. Die Attribute in einem Start-Tag werden nicht in irgendeiner speziellen Reihenfolge erkannt. Die Spezifikation macht keinen Unterschied zwischen <name first="Chris" last="Jones"> und <name last = "Jones" first = "Chris">.

Es gibt einige Einschränkungen beim Umgang mit Tags, die man kennen sollte. Zunächst gibt es eine Einschränkung bei Attributen: Sie müssen eindeutig sein. Ein Attributname darf im gleichen Start-Tag nicht doppelt vorkommen. Zweitens: Wenn das Dokument gültig sein soll, müssen die Attribute deklariert worden sein, und die Werte müssen die angegebenen Typen haben. Zusätzlich gilt, daß Attributwerte keine externen Entity-Referenzen sein oder solche enthalten können. Und schließlich darf ein Attribut eines Start-Tags oder sein Entity-Ersetzungstext das Zeichen < nicht enthalten. Was End-Tags angeht, verlangt die Spezifikation nur, daß deren Namen identisch mit denen der Start-Tags sind. Attribute sind in End-Tags nicht erlaubt.

Elemente können so ziemlich alle beliebigen Zeichendaten enthalten, solange sie nicht mit der umgebenden Auszeichnung selbst kollidieren. Das wurde bereits unter Text, Zeichendaten und Auszeichnungen behandelt.

Leere Elemente sind Elemente ohne Inhalt. Wie in diesem Beispiel gezeigt, dürfen sie jedoch Attribute enthalten:

<names>
   <name first="Chris" last="Jones"/>
   <name/>
</names>

Dieses Stück XML stellt zwei wohlgeformte name-Elemente dar. Beide sind leer, aber im ersten werden zwei Attribute angegeben.

Anführungszeichen um Attributwerte

Die Spezifikation definiert Literale als »alle in Anführungszeichen stehenden Strings, die nicht selbst das Anführungszeichen enthalten, das ihnen als Begrenzer dient«. Literale werden benutzt, um den Inhalt eines internen Entity und den Wert von Attributen anzugeben. Üblicherweise sehen Kombinationen von Attributen und Werten so aus:

 <account refnum="23908403"/> 

In diesem Beispiel ist refnum ein Attribut des account-Elements und hat den Wert 23908403. Es dürfen entweder einzelne oder doppelte Anführungszeichen benutzt werden – mit der Einschränkung, daß diejenigen Anführungszeichen, die zur Angabe des Wertes benutzt werden, nicht direkt im Wert selbst vorkommen dürfen. Sie dürfen jedoch über Entity-Referenzen oder numerische Zeichenreferenzen enthalten sein.

Als Beispiel für einen Attributwert, der beide Arten von Anführungszeichen enthält, benutzen wir folgenden Satz:

Die Katze sagte: "Der Hund schrie 'Hilfe!', dann schlug ich zu."

Als Attribut codiert, bekommen wir folgendes:

<talltale text='Die Katze sagte: "Der Hund schrie &apos;Hilfe!&apos;, dann schlug ich zu."'/>

Kommentare

Kommentare in XML sind ähnlich zu Kommentaren in HTML. Die Spezifikation besagt, daß Kommentare überall außerhalb von anderen Auszeichnungen vorkommen können. Ein einfacher XML-Kommentar sieht z. B. so aus:

<!-- Dies ist ein Kommentar. -->

Da Kommentare innerhalb von anderen Auszeichnungen nicht erlaubt sind, können Sie keinen Kommentar in einem XML-Start-Tag plazieren:

 <book name="Python und XML" <!--Kommentar hier-->> 

Diese Art von Ausdrücken ist in der XML-Spezifikation nicht zugelassen. Interessanterweise können Kommentare in einer DTD vorkommen. Außerdem gilt, daß Kommentare nicht als Teil der Zeichendaten eines Dokuments betrachtet werden. Zu den paar anderen Unzulänglichkeiten gehört, daß doppelte Bindestriche (--) nicht innerhalb des Kommentartextes benutzt werden können, da mit den Zeichen --> angegeben wird, daß der Kommentar dort zu Ende ist. Da es eines der Ziele von XML ist, syntaktische Probleme vorausgegangener Auszeichnungssprachen zu vermeiden, erlaubt XML ganz einfach keine doppelten Bindestriche in Kommentaren. Entities und andere Auszeichnungen werden im Kommentartext nicht behandelt, so daß Sie die sonst für XML speziellen Zeichen in Ihren Kommentaren verwenden können, ohne Syntaxfehler in Ihren Daten befürchten zu müssen. Die korrekte Version des vorigen kommentierten Elements lautet:

<book name="Python und XML">
   Dieses Buch handelt von der Programmiersprache Python und der Markup-Sprache XML.
   <!--Kommentar hier-->
</book>

Nachdem wir den Kommentar innerhalb des Elements statt im Start-Tag plaziert haben, entspricht er nun den Regeln.

Verarbeitungsanweisungen

Verarbeitungsanweisungen (Processing Instructions oder kurz PIs) ermöglichen es einem XML-Dokument, Anweisungen an eine verarbeitende Anwendung zu übergeben. Der XML-Prozessor betrachtet Verarbeitungsanweisungen nicht als Teil der Zeichendaten eines Dokuments. Der Sinn von PIs ist es, Informationen an eine Anwendung zu übergeben. Wenn Sie z. B. eine wichtige Nachricht weiterleiten und möchten, daß die empfangende Anwendung beim Benutzer eine Art Alarm auslöst, könnten Sie die folgende Anweisung im XML-Code plazieren, sodass verschiedene Anwendungen entsprechend reagieren können (ein Palm VII könnte z. B. piepen, eine X Window-Anwendung könnte ein Alarm-Dialogfenster öffnen und so weiter):

 <?newsAlert title="Invasion von Marsmenschen"?> 

In diesem Beispiel wird newsAlert gewöhnlich als das Target (Ziel) bezeichnet; der Rest des Textes hat keinen besonderen Namen. Die Unterscheidung zwischen den beiden Teilen der Verarbeitungsanweisung ist gänzlich eine Frage der Konvention; die Spezifikation schreibt nur <? zu Beginn, ?> am Ende und das Fehlen der zwei Zeichen ?> innerhalb der PI vor. (Beachten Sie, daß die meisten APIs zum Gebrauch mit PIs die beiden Teile als Target und Daten bezeichnen.) Für den Inhalt von Verarbeitungsanweisungen gibt es keine besondere Syntax, aber es wird empfohlen, jede mit einem Target zu beginnen (für gewöhnlich der Name des Werkzeugs, das sie verarbeitet). Es wird zunehmend üblich, daß Anwendungen als Inhalt nach dem Target eine Folge von Attributen mit Werten erwarten, die man oft als Pseudoattribute bezeichnet. Anwendungen können die PI in diesem XML-Dokument ganz nach Belieben behandeln oder ignorieren. Verarbeitungsanweisungen sind nützlich, weil sie einen XML-orientierten Weg bieten, Ereignisse zwischen Anwendungen weiterzugeben oder Anmerkungen zu Daten hinzuzufügen, die für spezielle Anwendungen von Interesse sind. Historisch betrachtet, wurden PIs in der SGML-Gemeinde benutzt, um Anweisungen für Formatierungsanwendungen zu codieren, mit einer Semantik der Art: »Füge hier einen Seitenumbruch ein.«

CDATA-Abschnitte

Ein CDATA-Abschnitt wird dazu benutzt, besondere Zeichen in den Zeichendaten Ihres Dokuments zu schützen. Beispiel:

 <![CDATA[Julius <aesar & Ma<beth]]> 

Tatsächlich ist dies eine Codierung der Zeichendaten:

 Julius <aesar & Ma<beth 

Wenn Sie keinen CDATA-Abschnitt verwenden, muß die Codierung mit allgemeinen Entities oder Zeichenreferenzen erfolgen:

Julius &lt;aesar &amp; Ma&lt;beth 

Der CDATA-Abschnitt ist eine gute Methode, um größere Textmengen mit vielen Zeichen zu schützen, die sonst als Auszeichnungen behandelt würden, wenn sie direkt im Text stünden. Beachten Sie, daß ein CDATA-Abschnitt mit der Auszeichnung <![CDATA[ beginnt; um das Wort CDATA herum ist kein Leerraum erlaubt. Innerhalb eines CDATA-Abschnitts wird so lange keine XML-Syntax erkannt, bis die Zeichen ]]> erreicht werden. Entity- und Zeichenreferenzen werden nicht aufgelöst oder erkannt, sodass der Text &#173; nicht durch das Symbol eines registrierten Warenzeichens ersetzt wird, obwohl das in normalen Zeichendaten oder in einem CDATA-Attributwert der Fall wäre.

  

<< zurück vor >>

 

 

 

Tipp der data2type-Redaktion:
Zum Thema Python & XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an:

Copyright © 2002 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "Python & XML" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de