Wolfgang Sommergut

Mit seinen unsauberen Praktiken im ISO-Standardisierungsprozess für OOXML führt Microsoft sein ruppiges Monopolistengehabe aus den 90er Jahren fort, das die Firma in den letzten Jahren nur mehr selten so offen zu Tage treten ließ. Nun könnte man argumentieren, dass eine gute Technologie notfalls auch mit Tricks zu einem offenen Standard befördert werden darf. Aber im Fall von OOXML passen Politik und Technik gut zusammen. Microsoft zeigt mit den neuen Office-Formaten, wie sich eine Standardsyntax (XML) nutzen lässt, um die Tradition proprietärer Dateiformate fortzuführen. OOXML demonstriert, wie sich das XML-Versprechen, Daten von der Anwendungen zu entkoppeln, systematisch aushebeln lässt.

Die Versuche, aus HTML- und XML-Markup ein Dateiformat für die Office-Anwendungen zu brauen, reichen bis auf die Version 2000 zurück. OOXML setzt in vielerlei Hinsicht fort, was damals begonnen wurde. Dazu zählt vor allem die Praxis, etablierte Techniken und Standards zu ignorieren sowie das Datenformat eng an die Eigenheiten der Office-Programme zu koppeln. Entsprechend sieht die Kritik an OOXML aus, das Microsoft erst nach Widerstand aus der amerikanischen Verwaltung als offenen Standard verabschieden wollte (die ursprünglichen Lizenzbedingungen sahen etwa vor, dass Anwendungen, die der GPL unterliegen, das neue XML-Format nicht benutzen dürfen). Hier ein paar Beispiele, warum sich OOXML schlecht für einen offenen Office-Standard eignet:

• Microsoft begründete die Entscheidung für ein eigenes XML-Format damit, dass dieses alle Eigenschaften der alten Binärdateien abbilden müsste. ODF dagegen sei darauf ausgelegt, möglichst portabel zwischen verschiedenen Anwendungen zu sein und daher nicht in der Lage, alle Funktionen von MS Office darzustellen. Es kann aber nicht Aufgabe eines Standards für Office-Dokumente sein, exakt die Eigenheiten einer bestimmten Software zu berücksichtigen. Vielmehr soll es den Austausch von Dokumenten zwischen Textverarbeitungen, Tabellenkalkulationen oder Präsentationsgrafiken verschiedener Hersteller erlauben.
• Microsofts Format verstößt gegen mehrere ISO-Standards. Das betrifft zum einen ODF, das bereits den Zweck eines herstellerübergreifenden Office-Formats erfüllt. Außerdem schreibt die Spezifikation Anwendungen vor, vom gregorianischen Kalender abzuweichen, der die Grundlage für ISO 8601 bildet (für die Kompatibilität mit einer alten Excel-Version soll das Jahr 1900 als Schaltjahr behandeln werden). Darüber hinaus verwendet Microsoft ein proprietäres Datumsformat, eigene Codes für Landessprachen (anstelle von ISO 639), Windows Metafile statt ISO/IEC 8632 (Computer Graphics Metafile).
• OOXML konkurriert außerdem mit Standards anderer Normierungsgremien. Das in Redmond erfundene DrawingML ersetzt die W3C-Empfehlung SVG und statt MathML entwickelte Microsoft eine eigene Notation für mathematische Formeln. Auf Kritik stößt zudem, dass sich Formatierungsangaben nicht an Standards wie CSS oder XSL orientieren, Microsoft eigene Codierungen für Farbwerte und Papiergrößen erfindet (statt der etablierten A4 oder Letter) sowie durch die ausgiebige Verwendung von Bitmasks den Einsatz von XSLT-Prozessoren limitiert.
• Der schwerwiegendste Einwand gegen OOXML besteht darin, dass die Spezifikation nicht ausreicht, um Software zu schreiben, die verlässlich Daten in diesem Format erstellen oder weiterverarbeiten kann. Ein Hauptargument von Microsoft für den Wechsel von den binären Formaten auf XML besteht seit Anfang an genau darin, dass die XML-Formate die Basis für IT-gestützte Geschäftsprozesse bilden können, weil sie sich an jeder Stelle von beliebiger Software weiterverarbeiten lassen. Die minuziöse Untersuchung von Stephane Rodriguez zeigt jedoch eindrucksvoll, dass sich selbst eine einfache Kalkulationstabelle – bestehend aus einer simplen Addition – gegen eine Ad-hoc-Veränderung durch externe Software sperrt. Und was helfen Vorgaben des Typs autoSpaceLikeWord95, die den Entwickler einer Software dazu zwingen, ein Verhalten von Word 95 nachzubilden, das nicht dokumentiert ist?

Die Ignoranz gegenüber bestehenden Standards könnten OOXML-Befürworter damit begründen, dass ein neuer Standard nicht unbedingt anerkannte Normen aufgreifen muss, wenn er etwa auf diese Weise ein komplexeres Problem lösen kann. In vielen Fällen würde dieses Argument aber nicht ziehen, etwa bei den proprietären Datumsformaten von OOXML, die keinen zusätzlichen Nutzen bieten. Außerdem lassen sich gerade XML-basierende Standards wie ODF über Namespaces elegant erweitern. Außerdem kann man sich kaum Formatierungsangaben vorstellen, die nicht über CSS oder XSL-FO abgedeckt werden – und falls doch, dann reicht es ja, dafür eigene Beschreibungen zu erfinden.

Im MS-Office-Umfeld hat dieser Umgang mit offenen Standards aber Methode, wie das Beispiel Infopath zeigt. Während andere große Anbieter von Software für elektronische Formulare (z.B. Adobe, IBM, OpenOffice) XForms nutzen, erfand Microsoft für diesen Zweck sein eigenes Format. In diversen Gesprächen mit Microsoft-Managern bekam auf eine entsprechende Frage immer den Hinweis, man könne das Infopath-Format ja leicht mittels XSLT nach XForms konvertieren. Wozu dann aber ein eigenes Datenformat?

Als das W3C vor elf Jahren die erste Spezifikation von XML verabschiedete, wurde das als großer Schritt für die Befreiung der Daten von proprietärer Software gefeiert. Aufgrund des Klartextformats und sprechender Feldbezeichner sollte es Anwendern möglich sein, die ihnen gehörenden Informationen so zu nutzen, wie sie es wollen – und nicht mehr auf Programme von bestimmten Herstellern angewiesen sein, die sie in undokumentierten binären Strukturen einsperren. OOXML zeigt, dass man auch mit einer von Menschen lesbaren Standardsyntax ein Dateiformat definieren kann, das sich nur schwer mit Software von Drittanbietern bearbeiten lässt (und menschenlesbar ist das hochgradig kryptische OOXML wohl kaum). Geradezu makaber ist dabei, dass Jean Paoli, einer der Mitautoren von XML 1.0, heute mit teilweise absurden Argumenten OOXML zu legitimieren versucht.

Siehe auch:
Freud und Leid mit XML-Dateiformaten
Fadenscheinige Argumente für Microsofts Office Open XML