Ja, es gibt sie, die Rufe nach einer zweiten, nach einer besseren Version von XML. Kompakter soll sie sein. Nicht so fehleranfällig. Ein bisschen wie HTML. Oder doch besser binär? Auf jeden Fall ohne die Altlasten, sprich DTDs. Folglich einfacher. Aber auch mächtiger.

Wer alles möchte, bekommt meist gar nichts. So viel ist klar. Gehen wir daher die Punkte auf der Wunschliste der Reihe nach durch und fragen uns: ist das wirklich wünschenswert?

Eierlegende Wollmilchsau
Seit Tim Berners-Lees Blogbeitrag Reinventing HTML wissen wir: XML im Web ist tot, zumindest im sichtbaren Web und nur was XHTML anbelangt, denn dort herrscht unangefochten HTML. Das dunkle, das nicht-sichtbare Web besteht dagegen größtenteils aus XML. XML verbindet Websites untereinander und mit Browser- sowie Desktopanwendungen. AJAX, REST, SOAP, ATOM sind hier die üblichen Verdächtigen.

Die Webdesigner haben XML dagegen seit Jahren links liegengelassen. Zu recht, denn sie sind es gewohnt, kreativ zu arbeiten, ohne strikte Vorgaben. HTML kommt ihnen da gerade recht. Egal, ob ein Element die korrekte Syntax besitzt oder nicht, Hauptsache der Browser stellt es wie gewünscht dar. Doch setzt HTML Fehlertoleranz mit Beliebigkeit gleich und Beliebigkeit bedeutet letztlich mehr Aufwand, für die Browser-Hersteller. Davon gibt es zum Glück nicht viele.

XML setzt dagegen auf Wohlgeformtheit und verlangt daher viel Disziplin. Und genau das ist der Vorteil von XML: es zwingt den Entwickler zu klaren Regeln und hilft dadurch Unsicherheiten zu vermeiden, denn Unsicherheiten schlagen sich im Quellcode nieder: mehr Code, um mehr Ausnahmefälle zu prüfen - das insbesondere vor dem Hintergrund von sicherheitskritischen Internet-Anwendungen.

Slim & Fast
Die nächste Forderung an eine zweite Version von XML ist die nach mehr Kompaktheit, also weniger Speicherverbrauch. Doch wieso ist das wünschenswert, wenn es das bereits gibt, ein kompaktes XML? Wer will, kann heute schon XML-Daten per ZIP-Algorithmus komprimieren und so über eine Schmalspurleitung, beispielsweise eine mobile Verbindung, jagen, oder platzsparend auf der Platte archivieren, so wie es die Standards OpenDocument und Office Open XML vormachen.

Wenn dann schon lieber ein Standard XML+ZIP. Aber auch den gibt es bereits: die Open Packaging Conventions leisten genau dies. Nur die Herkunft ist in den Augen mancher nicht die Beste: Microsoft.

Widerspruch in sich
Und noch eine Forderung, die oft, aber leise zu hören ist: nach einem binären XML. Ein Widerspruch in sich, wenn man sich die Zielsetzung von XML ins Gedächtnis ruft:

• "human-legible and reasonably clear" - "menschen-lesbar und leicht verständlich"
• "Sharing of data accross different information systems" - "Austausch von Daten zwischen verschiedenen Informationssystemen"

Einen Binärkauderwelsch versteht kein Mensch und das mit dem reibungslosen Datenaustausch zwischen verschiedenen Informationssystemen hat bei Binärformaten schon in der Vergangenheit nicht geklappt. Für letzteres gibt es zumindest einen technischen und einen menschlichen Grund. Der technische Grund ist simpel: Sonderzeichen haben auf unterschiedlichen Plattformen unterschiedliche Bedeutungen und erschweren so die Implementierung eines Formates auf verschiedenen Systemen. Menschlich betrachtet erhöhen Binärformate die Komplexität und überfordern damit oftmals selbst das Abstraktionsvermögen eines Entwicklers. Das kann nur zu einem führen: zu Fehlern.

Zwar gab es eine Arbeitsgruppe am W3C, die sich mit Binary XML beschäftigte, aber eine offizielle Empfehlung war von ihr nicht zu erwarten. Die sollte sie auch gar nicht liefern. Ihre Aufgabe war es nur, zu untersuchen, ob überhaupt Bedarf an einem binären XML besteht. Ihr Fazit: ja, den gibt es. Die Konsequenz: eine weitere Arbeitsgruppe mit dem Titel "Efficient XML Interchange Working Group". Ihr Ziel: ein Austauschformat, welches zwar konform zur XML-InfoSet-Spezifikation, nicht aber zur XML-Spezifikation ist, und das eine effiziente, das heißt sparsame Datenübertragung ermöglicht. Ihr vorläufiges Ergebnis: neun verschiedene Vorschläge für ein entsprechendes Format.

Altlastentsorgung
Dann gibt es noch den Vorschlag von Tim Bray, einem der Editoren von XML 1.0, die Spezifikation um Dokumenttyp-Definitionen, DTDs, zu erleichtern und um XML Namespace, XML Base und XML InfoSet zu erweitern. XML-SW nannte Tim Bray im Jahr 2002 seinen Vorschlag, für "XML-Skunkworks". "Skunk works", übersetzt "Stinktierarbeiten", sind halb- oder inoffizielle Projekte von Mitarbeitern eines Unternehmens und als solches ist auch XML-SW zu verstehen.

XML-SW ist keine schlechte Idee, doch wem nützt sie? Vier Spezifikation in eine zu verpacken, macht nichts besser. DTD fallen zulassen, würde dagegen die Entwicklung neuer XML-Parser vereinfachen. Aber lohnt das? Wohl kaum.

XML wurde für die Ewigkeit geschaffen oder zumindest für etwas, was in der schnelllebigen Welt der Informationstechnologie als Ewigkeit bezeichnet werden kann. Ein oder zwei Jahrzehnte also. Ein XML 2.0, welches DTD aus-, dafür XML Base, XML Namespaces und XML InfoSet einschließt, wäre zwar weitgehend, aber eben nicht mehr hundertprozentig kompatibel zu XML 1.0. Ein hoher Preis für eine kleine Vereinfachung.

Die zweite Version
Unveränderlich ist XML aber keineswegs. Denn es gibt sie, die zweite Version von XML: XML 1.1 heißt sie, bringt einige Verbesserungen im Umgang mit Unicode mit und ist kaum bekannt, geschweige denn im Einsatz.  Der Nutzen durch die Änderungen ist zu klein, der Aufwand, die XML-Parser umzuschreiben, dagegen im Vergleich zu groß und die Abwärtskompatibilität zu XML 1.0 nicht gegeben, kurzum das W3C empfiehlt auch weiterhin: XML 1.0.

Änderungsbedarf
Nein, ein Bedarf an XML 2.0 sehe ich nicht, aber an Werkzeugen und Bibliotheken, die sich an XML 1.0 halten. Qualität statt Fortschritt wünsche ich mir. Natürlich gibt es im XML-Universum Dinge, die sich verbessern lassen. XML Schema ist so ein Beispiel. Aber das ist ein anderes Thema für eine kommende Folge von Naked XML.

In diesem Sinne, bis in vierzehn Tagen

Ihr Martin Szugat

Martin Szugat beschäftigt sich seit der ersten Version mit XML. Hierüber sowie über weitere XML-Themen hat er zahlreiche Beiträge unter anderem für das dot.net magazin und den Entwickler geschrieben. Neben seiner Webkolumne Naked XML schreibt er auch regelmäßig an seinem Blog aboutxml.de.