Binäres XML vs. Excel

In diesem Beitrag möchte ich auf einige Ideen zu Binary XML und Excel hinweisen. Die XML Binary Characterization Working Group des W3C wurde im Sommer 2003 ins Leben gerufen und ihre erste Aktivität löste bei XML-Experten in aller Welt Protest aus. Das Konzept von Binary XML wurde schon früher diskutiert, wobei Ideen ausgetauscht wurden, warum ein weniger ausführliches XML notwendig ist. Vor einem Jahr veröffentlichte die XBC Working Group ihre Dokumente und setzte ihre Bemühungen in der Efficient XML Interchange Working Group fort, leider ohne allzu viel Interesse zu wecken. Das Problem ist, dass binäres XML ein völlig neuer Satz von Spezifikationen wäre, der neue Probleme mit sich brächte: Es wäre für den Menschen unlesbar, neue und aktualisierte Tools, Parser und Editoren wären erforderlich, und es müssten neue Vereinbarungen getroffen werden, z.B. für Wohlgeformtheitsvalidierungen. Warum erfinden wir ein binäres XML, wenn wir bereits eine vollkommen brauchbare Alternative haben: Microsoft Excel? Excel wird für alle möglichen Zwecke verwendet, auch für solche, für die es nicht konzipiert wurde: Anforderungen, strukturierte Spezifikationen, Nachrichten, Problemverfolgung, Stundenzettel, Projektmanagement, Zeitreihendaten und - natürlich - Berechnungen. Damit ist Excel genauso universell einsetzbar wie XML. Außerdem wird es bereits von unzähligen Benutzern weltweit verwendet. Heutzutage können auch Nicht-Microsoft-Tools das Excel-Dateiformat verarbeiten, so dass der Nutzen von Excel-Tabellen über die Microsoft Windows-Plattform hinausgeht. Eine Excel-Tabelle ist ein binäres Format, mit dem einfache Menschen umgehen können: Wir können diese Tabellenkalkulationsdateien in unserem bevorzugten Office-Paket öffnen und den Inhalt betrachten, analysieren und ändern. Das ist sogar noch benutzerfreundlicher als XML selbst! Kein Tag-Balancing mehr, kein Zeichen-Escaping mehr! Tabellenkalkulationen eignen sich hervorragend für den gemischten Nachrichtenaustausch zwischen Mensch und Computer. Ein Fragebogen oder ein Stundenzettel könnte beispielsweise als Excel-Vorlage bereitgestellt, von einem Benutzer ausgefüllt und von einem Verwaltungssystem verarbeitet werden, wobei die bevorzugte Tabellenkalkulationsanwendung des Benutzers und eine Software wie Jakarta POI zum Einsatz kommen. Es ist eine Schande, dass die meisten Tabellenkalkulationen nur von Benutzern verwendet und fast nie von einer Software verarbeitet werden, die eine sehr reale und praktische Option ist... Wann werden Unternehmen den ganzen Weg gehen und Tabellenkalkulationen verwenden, um c2b- oder b2b-Messaging zu implementieren?