Montag, 6. September 2010 |
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.