Mit der Veröffentlichung von OpenDocument als ISO-Norm und der Anerkennung von Microsofts “Office Open XML” durch die ECMA erreicht der Streit um das zukünftige Standardformat für Office-Dokumente eine neue Stufe.
Eine gute Einführung in das, worum es geht, bietet ein Interview mit Georg Greve von der FSFE über Das Dateiformat der Zukunft in der ORF Futurezone.
Greve bezieht sich in dem Interview auf die umfangreiche Diskussion zu diesem Thema im Internet. Leider sind die Quellen dazu nicht angegeben. Das versuche ich hier nachzuholen.
Binäre Daten in Microsofts OOXML
Die Microsoft-Formate haben ihren Hintergrund darin, Daten entlang der internen Struktur binär abzuspeichern. OpenXML bricht nur bedingt mit dieser Tradition, indem es die Daten in XML-Container speichert, dabei aber weiterhin auf proprietäre Datenformate von Microsoft setzt.
In dem Blogeintrag A bit about the bit with the bits zeigt Rob Weir, das “Office Open XML” einige Angaben (wie z. B. den Zeichensatz der verwendeten Schriftart) in binärer Form als Bitmaske speichert.
Eine Zeichenformatierung sieht in OOXML so aus:
<w:font w:name="Times New Roman"> <w:sig w:usb0="20002A87" w:usb1="80000000" w:usb2="00000008" w:usb3="00000000" w:csb0="000001FF" w:csb1="00000000"> ... </w:font>
Ein grundlegendes Problem daran ist, dass die binäre Repräsentation der Daten plattformspezifisch ist. Andere Systeme als Microsoft Windows müssen diese Binärdaten irgendwie übersetzen bzw. die Binärstruktur von Windows nachbilden.
Das ist auch der Grund, warum manche Kritiker meinen, dass OOXML nur eine XML-Verpackung um die alten proprietären Microsoft-Office-Formate ist.
Historische Merkwürdigkeiten in OOXML
Es ist im Wesentlichen aber eine Beschreibung von Microsofts Formaten, inklusive aller historisch gewachsenen Merkwürdigkeiten.
In einem anderen Blogeintrag A Leap Back zeigt Rob Weir am Beispiel der Datumsberechnung, dass sich OOXML so eng an die Programmstruktur von Microsoft Office hält, dass es selbst Merkwürdigkeiten übernimmt, die MS Office aus rein historischen Gründen mit sich herumschleppt. So berechnet Excel das Jahr 1900 als Schaltjahr, obwohl es gar kein Schaltjahr war. Die “Office Open XML (OOXML)”-Spezifikation übernimmt „aus Kompabilitätsgründen“ (“for legacy reasons”) diese Seltsamkeit inklusive der Komplikationen, die damit verbunden sind (wenn z. B. die Wochentage zwischen 1.1.1900 und 28.2.1900 berechnet werden müssen).
Rob Weir kommentiert:
The “legacy reasons” argument is entirely bogus. Microsoft could have easily have defined the XML format to require correct dates and managed the compatibility issues when loading/saving files in Excel. […] Sure this requires extra code to be added to Excel. Excel has a bug. Of course it will require code to fix a bug. Deal with it. I think the alternative of forcing the rest of the world to adopt a new calendar system is the ultimate in chutzpah.
OpenXML als Einbahnstraße
Weiter meint Greve im Interview:
Wer also Microsofts Format vollständig umsetzen will, müsste im Wesentlichen nicht nur OpenXML implementieren, was Andrew Shebanow von Adobe an Hand der Angaben von Microsoft auf einen Aufwand von 250 Personenjahren eingeschätzt hat, sondern eben auch die proprietären Formate, die in OpenXML eingebettet sind, was vermutlich bedeutet, große Teile von Windows nachbauen zu müssen, wie Bob Sutor von IBM bereits ausgeführt hat.
In dem Blogeintrag Is Office Open XML A One-Way Standard? Ask Microsoft kommentiert Andrew Shebanow den Blogeintrag Open XML Converters for Mac Office des Word-für-Mac-Koordinators Rick Schaut, in dem dieser begründet, warum es noch einige Zeit dauern wird, bis Microsoft Word für Mac das neue Microsoft-Dateiformat unterstützen wird. Schaut schätzt, dass ein Team von 5 Personen annähernd ein Jahr braucht, um einen Konverter zu schreiben, damit Word für Mac das neue Dateiformat lesen kann. Daraus berechnet Shebanow, wieviele Personenjahre nötig sind, um Konverter zum Lesen und Schreiben der neuen Dateiformate für alle Office-Komponenten zu entwickeln – also auch Excel und Powerpoint.
Bob Sutor von IBM argumentiert in seinem Blogeintrag Is Open XML a one way specification for most people? aufgrund der oben genannten Argumente (historische Merkwürdigkeiten und binäre Daten), dass man für eine vollständige Implementierung von OOXML große Teile der internen Struktur von Microsoft Office nachbauen muss:
Fully and correctly implementing Open XML will require the cloning of a large portion of Microsoft’s product.