XML entstand wohl hauptsächlich aus der Motivation heraus, ein besseres HTML zu schaffen, und dürfte jedem, der sich bis hierhin durchgekämpft hat, ein Begriff sein. Ansonsten sei auf die Übersicht auf [XML-W3C] oder die offizielle Spezifikation [XML-Specification] verwiesen. Wir versuchen die für unser Thema interessanten Dinge also lieber direkt anhand eines konkreten Beispiels herauszubekommen:
<?xml version='1.0' encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang="EN"> <head> <title>XML-Beispiel</title>
</head> <body> <h1>XML-Beispiel</h1>
</body> </html>
Dieses Beispiel hat den Vorzug, dass es sowohl gültiges XML als auch gültiges (X)HTML ist.
| Das Attribut encoding der XML-Deklaration bestimmt die Kodierung des Dokuments. Fehlt dieses Attribut, ist das Dokument in UTF-8, der Standardkodierung für XML kodiert. |
| An diesen beiden Stellen enthält das Dokument Text im konventionellen Sinne, auch Content genannt. |
| Der Wert des Attributs alt des Elements img ist insofern etwas Besonderes, als es ein Mittelding zwischen Markup (also Element- und Attributnamen) und Content darstellt. |
Die Bestandteile eines XML-Dokuments lassen sich nach dem obigen Schema grob klassifizieren. Markup bildet das abstrakte Gerüst des Dokuments, die eigentliche Information ist in der Regel als Inhalt von Elementen vorhanden, Attributwerte können irgendwo dazwischen liegen. Worauf bezieht sich jetzt die Angabe encoding in der XML-Deklaration? Lediglich auf die eigentliche Information? Nein, auf das gesamte Dokument, inklusive Markup. Wer dabei jubelt hat es noch nie unternommen, einen Parser für XML zu schreiben, denn genau hier liegt einer der Gründe, weshalb XML-Applikationen so elend langsam, und daher in der Praxis selten so zu gebrauchen und einzusetzen sind, wie man beim W3C träumt.
Die Intention ist klar: Es soll möglich sein, XML-Formate in beliebigen natürlichen Sprachen zu definieren, während man sich bei derlei Unternehmungen normalerweise auf US-ASCII beschränkt. Die Krux des Features tritt allerdings zutage, wenn man tiefer in die Spezifikation einsteigt. So sind für Elementnamen so ziemlich alle Unicode-Zeichen außer Whitespace (nicht druckbare Zeichen wie Leerzeichen, Tabulatoren, Zeilenumbrüche, etc.) erlaubt. Dazu gehören allerdings auch ideographische Leerzeichen, also Zeichen, denen in Unicode die entsprechende Eigenschaft zugeordnet wurde.
Welchen Unicode-Zeichen jedoch welche Eigenschaften zugeordnet werden, ist keineswegs für alle Ewigkeit klar. Bei einigen Zeichen gibt es Uneinigkeit über die Klassifikation, und die Zuordnung kann sich auch durchaus einmal ändern. Ein XML-Dokument, das heute noch gültig ist, könnte also nach einer Änderung des Unicode-Standards plötzlich ungültig sein. Selbst, wenn dies nicht so wäre, stellt das Parsen von XML aber noch immer eine echte Herausforderung dar, weil die für die einzelnen Bestandteile erlaubten und nicht-erlaubten Zeichen keineswegs in kontinuierlichen Bereichen liegen, sondern bunt über das Spektrum verteilt sind. Die Definition der sogenannten Basis-Zeichen in http://www.w3.org/TR/REC-xml#NT-BaseChar mag als abschreckendes Beispiel genügen.
Anhänger des XML-Hypes wenden gegen derlei Blasphemie gerne ein, dass eines der Design-Ziele von XML die Lesbarkeit durch Menschen sei, Knappheit ist ausdrücklich kein Design-Ziel. Die meisten XML-Dokumente werden allerdings auch dann nicht wirklich zur unterhaltsamen Lektüre, wenn man die Elementnamen ohne weiteres versteht ...
Der Wert von XML soll hier keineswegs pauschal in Abrede gestellt werden. Die hehren Ziele, die beim Design von XML verfolgt wurden, schränken allerdings die praktische Brauchbarkeit stark ein, und man sollte sich vor der Verwendung von XML darüber im Klaren sein, dass es sich bei den fantastischen Anwendungsmöglichkeiten meistens noch um Tagträumereien handelt, die in der Praxis einfach an Performance- und Lastproblemen scheitern. Eine gern beschriebene Anwendungsmöglichkeit sieht so aus, dass Web-Server alle Daten nur noch in XML vorhalten, und dann bei Bedarf durch ein Stylesheet jagen, und in fast beliebige Zielformate wandeln. Nun, dieses Dokument ist in XML geschrieben, und wird via XSLT in HTML und PDF gewandelt. Die Umwandlung in HTML dauert zur Zeit 35 Sekunden, wird zusätzlich noch eine PDF-Version generiert, dauert es schlappe anderthalb Minuten. Auf Webseiten, die mithilfe solcher Techniken generiert werden, sollte man es daher nicht versäumen, die Nummer eines Telefonanschlusses anzugeben, der von sachkundigen Mitarbeiterinnen betreut wird, die sich darauf verstehen, den ignoranten Besuchern der Webpräsenz die Vorzüge von XML zu vermitteln. An mangelnder Zeit dafür soll es nicht scheitern ...
Wie gesagt, XML kann sicher nutzbringend eingesetzt werden, es erleichtert insbesondere den Datenaustausch, nicht zuletzt weil die Kodierung von Textdaten stets eindeutig festzustellen ist. Seine Tauglichkeit als Speicherformat darf allerdings zum jetzigen Zeitpunkt bezweifelt werden. An Schnittstellen zu anderen Applikation ist XML sehr nützlich. Um Konfigurationsdateien, die ohnehin nur von der eigenen Software gelesen und verstanden werden, abzuspeichern, wird man sicher besser geeignete Formate finden.
Ein großer Vorzug von XML ist die Eindeutigkeit der Daten. Allerdings wird die heile Welt durch ein zweifelhaftes Feature auf Windows-Systemen doch etwas getrübt. In Abschnitt 4.1.2, „UTF-16“ wurde das Byte Order Mark BOM erwähnt. In 2- und 4-Byte-Kodierungen ist diese Markierung nützlich, um die Byte-Ordnung der Daten zu ermitteln, für Multi-Byte-Encodings wie UTF-8 ist es überflüssig, und sollte ignoriert werden.
Dieser Umstand wird von Windows-Applikationen (der Minimal-Editor Notepad ist ein Beispiel hierfür) „missbraucht“, um beliebige Textdateien als utf-8-kodiert zu kennzeichnen, indem nämlich genau die UTF-8-Darstellung des BOM am Anfang der Datei eingefügt wird. Daran ist prinzipiell nichts auszusetzen, es ist ein cleverer Trick.
Für XML hat dies allerdings fatale Konsequenzen: Editiert man eine XML-Datei, die in UTF-8 kodiert ist (oder es sein sollte) mit einem solchen Editor, fügt dieser das Zeichen ebenfalls ein, obwohl dies nach dem XML-Standard nicht erlaubt ist (XML-Dateien müssen immer, sofern sie nicht in 2- oder 4-Byte-Kodierungen vorliegen, mit dem Zeichen „<“ beginnen); das BOM ist aber kein Kleinerzeichen.
Sowohl der Internet Explorer als auch Mozilla nehmen diese Verletzung des Standards stillschweigend hin, selbst der aus dem Unix-Bereich stammende Editor vim stört sich nicht daran, und interpretiert das BOM in Notepad-Manier (und speichert es auch wieder mit ab). Echte XML-Parser brechen jedoch bereits zu Anfang mit einem fatalen Fehler ab, und das zurecht.
Man mag das Problem als wenig relevant abtun, weil etliche Standard-Applikationen diesen Fehler ja akzeptieren. Problematisch ist jedoch, dass sich der Fehler aus den Dateien nicht mehr eliminieren lässt. Hat man eine XML-Datei einmal mit dem Notepad verunstaltet, wird es mit dem selben Programm nicht gelingen, den Fehler wieder zu entfernen. Erkennbar ist er ebenfalls nicht, weil die Programme, die den Standard an dieser Stelle ignorieren, die illegalen Zeichen ja noch nicht einmal darstellen.
Welche Programme sonst noch diesen Fehler verursachen, ist nicht bekannt. Es darf jedoch vermutet werden, dass das Notepad nicht der einzige Bösewicht ist und bleibt.
Die Bestimmung der Sprache geschieht in XML durch das Attribut xml:lang. Dieses spezielle Attribut ist unabhängig von der konkreten DTD immer, und mit der gleichen Semantik erlaubt. Inhalt des Attributs ist ein Sprachkürzel, wie es auch in HTTP verwendet wird, also beispielsweise de, en-us, fr-ch. Groß-Kleinschreibung spielt bei der Interpretation des Attributes keine Rolle.
Das Attribut gilt jeweils für das Element, in dem es verwendet wird und für alle Unterelemente. Unterelemente „erben“ den Wert also. Mithilfe dieses hierarchischen Konzeptes ist es daher möglich, beliebige Teilbäume in verschiedenen Sprachen zu verfassen und entsprechend zu kennzeichnen (für das Charset fehlt eine solche Möglichkeit leider, obwohl dies in der Praxis, insbesondere bei der manuellen Erstellung von XML-Daten durchaus nützlich wäre).
Einen Standardwert für das Attribut xml:lang kennt XML ebensowenig wie HTTP.
Wird ein XML-Dokument über HTTP ausgeliefert (mit dem Medientyp text/xml) dürfte man davon ausgehen, dass die empfangende Applikation einen Content-Language-Header ebenfalls beachtet, und dessen Wert auf das komplette Dokument bezieht. Da alle gängigen Web-Browser die Dokumentensprache zur Zeit noch ignorieren, lässt sich diese Annahme jedoch nicht eruieren.