Das ist hier nicht die Frage! Denn es muss nicht immer XML sein. Es darf auch beispielsweise mal ein Binärformat sein. Doch die Frage ist: Wann verwende ich was? Eine Antwort gibt es nicht, sondern viele.

Tear down this wall
Nein, diese Worte stammen nicht vom XML-Erfinder (den es so ja auch nicht gab), sondern von Ronald Reagan. Er richtete sie anlässlich seines Besuches im damaligen von der Mauer geteilten Berlin an " Mr. Gorbachev". Genauso gut hätte aber auch das W3C ausrufen können: "Mr. Developer, tear down this wall!".

Gemeint sind die Anwendungsgrenzen. Es geht also darum, die eigene Anwendung, sei es im Web oder auf dem Desktop, für andere Anwendungen zu öffnen und so eine Schnittstelle zu den Anwendungsdaten zu schaffen. Das erfordert (mindestens) Dreierlei: Erstens müssen die Anwendungen alle dieselbe Sprache sprechen, egal welche, Hauptsache dieselbe. Ein "Besser" oder "Schlechter" gibt es hier nicht. Zweitens müssen die Anwendungen die Sprache auch grundsätzlich verstehen können, also zumindest die Zeichen kennen, auf denen sie baut. Hier steht "Besser" für "Universeller". Und drittens müssen die Anwendungen die Satz- oder Steuerungszeichen einheitlich interpretieren.

Punkt 1 ist weniger technischer, denn sozialer Natur: ein Standard ist ein Standard, weil alle ihn als Standard akzeptieren. XML ist ein Standard. (Ein Standard muss nicht einmal ein besonders guter Standard sein, damit ihn alle als Standard akzeptieren. Es reicht oft schon aus, dass er der erste Standardanwärter war.)

Punkt 2 ist technisch und wird trotzdem gerade von den Entwicklern meist völlig unterschätzt. ASCII herrscht auf dem PC, doch nicht über die Mainframes. Kurzum, es geht um Zeichencodes. Und hier lautet die Lösung: Unicode (auch "Universal Character Set" genannt – man beachte das "Universal"). XML basiert auf Unicode.

Punkt 3 ist eine Frage der Konvention und damit auch des Geschmacks. Ein Zeilenumbruch ist nicht gleich einem Zeilenumbruch – zumindest nicht unter Windows und Linux. Er eignet sich also kaum als Trennzeichen in strukturierten Daten, ebenso wenig wie die übrigen Leerraumzeichen. Tab oder Leerzeichen – wer erkennt den Unterschied in einem einfachen Texteditor? XML macht Schluss mit diesem Unfug und führt stattdessen die spitzen Klammern an.

Die Welt spricht XML
XML ist also vor allem eines: ein Datenformat, um Grenzen zu überwinden. Seien es Anwendungsgrenzen: (fast) alle Programmiersprachen unterstützen XML. Oder Sprach- und Landesgrenzen: arabische, kyrillische, japanische oder chinesische Schriftzeichen – kein Problem für Unicode. Rechnergrenzen: Linux, Windows oder was auch immer – das interessiert XML nicht.

Somit eignet sich XML vor allem für eines: für den grenzenlosen Datenaustausch zwischen Anwendern und zwischen Anwendungen. Und genau dafür wird es auch primär genutzt: RSS tauscht Nachrichtenmeldungen zwischen Publisher und Consumer aus, SOAP Prozeduraufrufe zwischen Client und Webservice und AJAX Benutzereingaben und Ausgaben zwischen RIA und Webserver.

Doch mit diesen Aufgaben ist XML nicht allein: JSON macht XML im AJAX-Bereich Konkurrenz und Hessian im Bereich der Web Services. Beiden Formaten ist gemein: sie sind kompakter als XML, benötigen demnach weniger Platz auf der Leitung. Hessian fällt hierfür sogar in die Binärzeit zurück. JSON verzichtet auf die Metadaten.

Der Vergleich hinkt folglich: denn XML ist eine Metasprache, also ein Beschreibungsformat, das Datenformate wie SOAP und RSS erst ermöglicht. Und obgleich auch Hessian und JSON in mehreren Programmiersprachen zuhause sind, die Akzeptanz von XML haben sie noch nicht erreicht.

Wer also sicherstellen möchte, dass auch wirklich jeder mit der eigenen Soft- oder Webware kommunizieren kann, der kommt an einer XML-Schnittstelle nicht vorbei. JSON, Hessian & Co. machen da Sinn, wo dies nicht gewollt oder nicht wichtig ist. Sie machen es für den Entwicklern meist einfacher, das Backend mit dem Frontend zu verknüpfen, weil sie auf Einfachheit setzen, also Komplexität dadurch reduzieren, dass sie Optionales weglassen und nur das Notwendige ermöglichen.

Datenbunker
Apropos Backend: auch hier kommt XML zum Einsatz und zwar zur Datenspeicherung. Doch gerade hier wurden die größten Dummheiten begannen. Alles musste XML sein, auch die Datenbank. Es ist aber auch bequem: eine Tabelle mit zwei Feldern. Das erste Feld enthält eine eindeutige Kennung, das zweite die Daten in einem XML-Format. Relationale Datenbankschema, darüber muss man sich dann glücklicherweise keine Gedanken mehr machen.

Falsch. XML ist hier nicht die Lösung, sondern nur der Anfang. Denn auch hier gilt es, die Daten mittels eines XML-Schemas zu beschreiben. Arbeit hat man sich damit nicht gespart. Sie ist nur aufgeschoben (in die Programmierung, die jetzt die Validierung übernehmen muss). Und performant ist die Lösung auch nicht. Im Gegenteil! Datenabfragen erfolgen nicht mehr auf dem Datenbankserver, sondern im Anwendungscode.

XML sollte kein Ersatz für relationale Datenbanken sein. Strukturierte Daten gehören in eine Datenbank. Nur so erreicht man die notwendige Performance und Skalierbarkeit. Bei semistrukturierten Daten sieht die Sache schon anders aus. Hier sind die speziellen XML-Datenbanken eine große Hilfe. Doch auch die Hersteller von relationalen Datenbanksystemen haben verstanden: XML ist nur ein weiterer Datentyp neben Zeichenfolgen, Datumswerten und Fließkommazahlen. Sie integrieren folglich XML und verstärkt XQuery in ihre Produkte. Eine XML-Import/Export-Schnittstelle gehört hier übrigens schon längst zum guten Ton.

Filesharing
Dateien sind da, um Daten zu speichern – und sie auszutauschen! Dateien sind kompakte Dateneinheiten und lassen sich (im Unterschied zu Datenbanken) einfach kopieren und versenden. Damit steht fest: XML im Dateisystem ist eine sinnvolle Angelegenheit.

Stop! So einfach ist die Sachlage dann noch nicht. Klar macht XML bei Dokumentformaten Sinn, denn Dokumente wollen zwischen Anwendern ausgetauscht, in verschiedenen Anwendungen geöffnet und auch für nachfolgende (Programm- und Anwender-)Generationen archiviert werden. Und auch für Konfigurationsdateien ist XML das passende (Meta-)Format. In der Theorie liest zwar nur einer eine Konfigurationsdatei: das Programm, das sich konfigurieren möchte. In der Praxis liest aber auch der Administrator und nur allzu oft ebenso der Endanwender eine Konfigurationsdatei: um festzustellen, was den schief läuft und warum es dies tut. Gut, wenn er die Datei dann auch notfalls von Hand bearbeiten kann.

Doch warum sollte jemand versuchen, umfangreiche Binärdaten in ein Textformat wie XML zu pressen? Genau da stößt XML an seine Grenzen. Egal wie man es anstellt, die binären Daten, beispielsweise Bitmaps, müssen codiert werden, meist mittels Base64. Das bereitet XML Magenschmerzen, es bläht das XML-Dokument auf und die Anwendung wird träge.

Die Lösung lautet hier: Outsourcing. Auslagern der binären Daten in separate Dateien und gegebenenfalls mittels XLink im XML-Dokument darauf verweisen. Oder es wie OpenDocument und OpenXML machen: das XML und die Binärdateien in ein gemeinsames ZIP-Archiv verpacken.

Fazit
XML ist zwar die beste allgemeine Lösung, aber nicht allgemein die beste Lösung. Das heißt: mit einer XML-Schnittstelle oder einem XML-Format liegen Sie meistens richtig, aber leider nicht immer. Manchmal muss es eben doch ein Binärformat sein, wenn beispielsweise die Bandbreite wie bei einer mobilen Verbindung begrenzt ist.

Martin Szugat schreibt, spricht und bloggt über XML (im dot.net magazin, auf der BASTA und unter aboutxml.de). Er entwickelt mit XML und er berät Unternehmen bei der Softwareentwicklung mit XML. Sein erster Rat lautet: "Drum prüfe [XML], wer sich ewig bindet".