XML

<?xml version=„1.0“ encoding=„UTF-8“ standalone=„yes“?> <Auftrag> <Kopf> <AuftragsNr>4711</AuftragsNr> <KundenNr>K0815</KundenNr> <Auftragsdatum>2013-05-30T00:00:00+2</Auftragsdatum> </Kopf> <Positionen> <Position nr=„1“> <ArtNr>S123</ArtNr> <Menge>5</Menge> <Einzelpreis>9.99</Einzelpreis> </Position> <Position nr=„2“> <ArtNr>H456</ArtNr> <Menge>3</Menge> <Einzelpreis>17.95</Einzelpreis> </Position> </Positionen> </Auftrag>

Zuallererst muss gesagt werden, dass die Zeilenumbrüche und Einrückungen in obigem Beispiel der besseren Lesbarkeit dienen. Oft werden Sie Dokumente so formatiert vorfinden, aber im Prinzip kann auch alles in einer Zeile direkt hintereinander stehen. Das ist für die Bedeutung völlig egal. Whitespaces (Zeilenumbruch, Leerzeichen, TAB) außerhalb von Werten haben keinerlei Wirkung. Sollten in bestimmten Werten (beispielsweise Artikelbeschreibungen) Zeilenumbrüche vorkommen, werden die natürlich übernommen. Und nun zu den Bestandteilen.

Eingeleitet wird die XML-Datei vom XML-Header. Der nennt die Version des XML-Formats (eigentlich immer 1.0) und das Encoding, in dem die Datei vorliegt. Außerdem ist hier mit standalone=“yes“ angegeben, dass diese Datei nicht zwingend gegen eine Formatdefinition geprüft werden muss. Mehr dazu etwas später. Dieser Header sollte eigentlich immer
existieren, es gibt aber reichlich Beispiele für XML-Dateien, die ohne daherkommen.

Allgemein nennen sich Angaben, die in <? und ?> geklammert sind, „Processing Instructions“. Dieser Header sieht auch so aus, ist aber technisch eigentlich keiner. Processing Instructions haben keine direkte Bedeutung für den Daten-Inhalt, daher beschäftigen wir uns nicht näher damit.

Die Bezeichner zwischen < und > nennt man Tags (gesprochen: Täg). Jedes Tag wird, so es nicht ohne Inhalt in der Gegend herumsteht, geöffnet und wieder geschlossen. Man spricht auch vom öffnenden und vom schließenden Tag. Das schließende Tag enthält einfach noch einen Slash / vor dem Bezeichner.

• • Auf oberster Ebene, also ohne selbst „Kind“ eines „Vater-Tags“ zu sein, darf es nur exakt einen Tag pro Datei geben: Das sogenannte Root-Tag. Eine XML-Datei, die mehr als ein (öffnendes und sein schließendes) Tag auf oberster Ebene hat, ist ungültig.
  • Ein Tag kann einen einfachen Wert beinhalten, wie hier: <AuftragsNr>4711</AuftragsNr>
  • Ebenso möglich ist, dass ein Tag weitere Tags beinhaltet, und das beliebig tief geschachtelt. Das obige Beispiel zeigt das sehr schön.
  • Ein Tag selbst kann durchaus mehrfach auftreten. So könnte man z.B. die Einordnung eines Artikels in eine Katalogstruktur so darstellen:

<Artikel nr="4711" name="Lernspiel abc">
  <Warengruppe>Lernen</Warengruppe>
  <Warengruppe>Spiele</Warengruppe>
  <Warengruppe>Schule</Warengruppe>
  <Warengruppe>Kinder</Warengruppe>
</Artikel>

Immerhin passt der Artikel in alle vier Gruppen thematisch gut rein.
Und der Auftrag in unserem Anfangsbeispiel hat ja auch mehrere Positionen.

• • Neben Werten und anderen Tags kann so ein Tag auch noch beliebig viele Attribute haben, wie dieses hier: <Position nr=“2″> … </Position>
    Der Wert eines Attributs wird – anders als im alten HTML – immer in „“ gesetzt.
    Attribute stehen grundsätzlich im öffnenden Tag. Wichtig ist, dass ein Attribut in einem Tag nur einmal auftauchen kann.
    So was geht also nicht: <Position nr=“2″ nr=“3″> Wäre auch irgendwie seltsam, welche Nummer hat die Position denn nun?
  • Und, besonders schön: Ein Tag kann alles auf einmal beinhalten:

<Obertag attr1="bla" attr2="fasel" attr3="dingens">
  <Untertag1 noch_n_attr="Vroni">
    <UnterUntertag_a>Halli</UnterUntertag_a>
    <UnterUntertag_b>Hallo</UnterUntertag_b>
    <UnterUntertag_c>Hallöle</UnterUntertag_c>
     Das ist der Wert vom Untertag 1.
  </Untertag1>
  <Untertag2>Ja servus!</Untertag2>
  Das ist der Wert vom Obertag.
</Obertag>

• Sollte ein Tag mal weder Wert noch Untertags beinhalten, kann es auch verkürzt geschrieben werden. Man zieht öffnendes und schließendes Tag zusammen:
  <Tag_ohne_Inhalt attr1=“Attribute dürfen sein“ />
  Sie sehen den Slash / am Ende? Der sagt, das Tag ist hier gleich wieder zu Ende. Es folgt kein schließendes Tag mehr.
• Kommentare werden mit <!– eingeleitet und mit –> wieder geschlossen. Sie dürfen über mehrere Zeilen gehen, nur zwischen einzelnen Tags stehen und niemals geschachtelt werden.

Und damit wäre eigentlich der Aufbau von xml auch schon ausreichend beschrieben. So weit, so einfach. Aber ein Bisschen kommt da noch.

Was passiert, wenn ein < oder ein > in einem Wert vorkommen? Das würde jeden XML-Parser aus dem Tritt bringen. Der sieht plötzlich ein < und denkt, da geht ein neues Tag auf. Dabei steht da eigentlich nur „a < b“. Damit der Parser nicht verzweifelt, maskiert man solche Zeichen, und zwar mit sogenannten Entitäten (engl.: entities). Aus einem < wird &lt;. Jede Entität beginnt mit einem Ampersand (alias Kaufmanns-Und) & und endet mit einem Strichpunkt ;. Dazwischen steht der Code für das Zeichen. In &lt; steht das „lt“ für „lower than“, also „kleiner als“. Entsprechend wird das > mit &gt; codiert, „gt“ für „greater than“, also „größer als“. Und da hiermit das Ampersand & auch seine Spezialbedeutung bekommen hat, muss auch dieses codiert werden: &amp;. Sie erraten es sicher: „amp“ für „Ampersand“. Der Strichpunkt ; muss nicht codiert werden. Da er ja nur dann etwas gilt, wenn vorher ein & mit passendem Code steht, verwirrt ein alleinstehender Strichpunkt den Parser nicht. Was aber gar nicht gut ist, sind Anführungszeichen “ in Attributwerten. Zumindest da müssen auch sie codiert werden und zwar mit &quot; („quot“ für „quotation mark“). Und, zu guter Letzt, auch das einfache Anführungszeichen alias Apostroph ‚ muss maskiert werden: &apos; Übrigens darf man auch die Zahlenwerte der ASCII- bzw. Unicode-Codes der maskierten Zeichen zwischen & und ; schreiben. Aber die sind nicht so gut zu merken wie lt, gt, amp, quot und apos. Wer noch die Erfahrung gemacht hat, HTML-Seiten im Texteditor zu erstellen (vi rules!), wird nun sofort an die vielen weiteren Entitäten denken, die er dort benutzt hat. Zum Beispiel &Auml; für das große Ä oder &szlig;
für das scharfe ß. Das kommt noch aus einer Zeit, als das Netz praktisch nur ASCII kannte. Da musste alles, was nicht im ASCII-Code vorkam, so codiert werden. Inzwischen schreibt man auch in HTML-Seiten oben das Encoding rein (wenn man sauber arbeitet), und die Browser kommen heute auch eigentlich alle mit Latin1 und Unicode klar, sodass das Codieren von Umlauten & Co. entfällt.

Was die Schreibweisen angeht, gilt zuallererst: XML ist case sensitive, will heißen, die Groß-/Kleinschreibung ist wichtig. Also ist Das nicht gleich das nicht gleich DAS. Bitte beachten Sie das unbedingt. Auf manchen Systemen wird man ja zur Schludrigkeit erzogen. Außerdem gibt es noch ein paar Regeln für Bezeichner, also die Namen von Tags und Attributen. Leerzeichen sind auf jeden Fall tabu. Sie trennen immerhin Tagnamen und Attribute in einem Tag. Auch Entitäten dürfen nicht enthalten sein. Bei Sonderzeichen wie Umlauten muckt auch der eine oder andere Parser. Kurz, nur folgende Zeichen sind erlaubt:
Kleine oder große Buchstaben (a-z|A-Z), Ziffern, Unterstrich _, Bindestrich – und der Punkt. Doppelpunkte haben eine Sonderbedeutung und werden weiter unten noch behandelt. Außerdem darf kein Bezeichner mit „xml“ (egal ob groß, klein oder gemischt geschrieben) beginnen. Das ist für spezielle Zwecke reserviert.

Wir sprechen hier im folgenden explizit von Daten-XML-Strukturen. Da ist einiges einfacher. Es gibt auch noch Dokumenten-Strukturen. Zum Beispiel werden Dokumente von Open Office, Neo Office, KOffice usw. ebenfalls in einem XML-Format gespeichert. Eine Datei des Open Document Formats ist letztlich nichts anderes als ein ZIP-Archiv mit einer Handvoll XML-Dateien (und evtl. eingebetteten Bildern etc). Eine davon – und zwar normalerweise die weitaus größte – enthält z.B. den Text aus OO-Writer. Hier gelten ganz besondere Regeln, beispielsweise ist die Reihenfolge aller Elemente innerhalb einer Datei enorm wichtig. Wenn Sie sich noch mal die obigen Beispiele ansehen, egal ob den Auftrag oder Artikel mit seinen Warengruppen, ist schnell erkennbar, dass hier die Reihenfolge herzlich egal ist. Die Positionen enthalten das Attribut nr und die Warengruppen des Artikels können auch beliebig umgestellt werden. Na gut, das „Halli Hallo Hallöle“ im letzten Beispiel verliert irgendwie seinen Witz, wenn man’s umstellt, …
Die folgenden Regeln gelten also für XML-Dateien, die reine Daten ohne Dokumentcharakter transportieren (wenn auch einige in beiden Fällen angewandt werden können):

• Wenn weder Wert noch Untertags gegeben sind, ist die Kurzform immer äquivalent zur langen Schreibweise aus öffnendem und schließendem Tag:
  <Tag attr=“abc“></Tag> ist gleichwertig mit <Tag attr=“abc“ />
• Ein vollständig leeres Tag (also auch ohne Attributwerte) kann auch ganz weggelassen werden: <Leer /> kann entfallen.
• Hat ein Attribt keinen Wert, kann es ebenso weggelassen werden: <Tag leer=““ >wert</Tag> ist gleichwertig mit <Tag>wert</Tag>
• Die Reihenfolge von Tags oder Attributen ist irrelevant. Jegliche Ordnungskriterien werden durch die Daten, wie z.B. eine Positionsnummer im Anfangsbeispiel, dargestellt.

  
  <Obertag attr1="bla" attr2="fasel" attr3="dingens">
    <Untertag1>Text1</Untertag1>
    <Untertag2 attr1="a" attr2="b" attr3="c">Text2</Untertag2>
    <Untertag3>Text3</Untertag3>
  </Obertag>

  ist äquivalent zu:

  
  <Obertag attr1="bla" attr3="dingens" attr2="fasel">
    <Untertag2 attr3="c" attr2="b" attr1="a">Text2</Untertag2>
    <Untertag3>Text3</Untertag3>
    <Untertag1>Text1</Untertag1>
  </Obertag>

Leider muss nun noch gesagt, werden, dass vor allem viele „selbstgestrickte“ XML-Parser das anders sehen. Da wird dann schon mal ein leeres Tag zwingend erwartet, und zwar nur in einer ganz bestimmten Form (<lang></lang> oder <kurz />). In manchen Datenformaten hat auch die Reihenfolge der Tags eine Bedeutung, statt auf saubere Attribute wie z.B. oben bei den Positionsnummern zu setzen