OesterBlog

Die letzte Zeit konnte man viel über DIS 29500, so der Name in der Technischen Arbeitsgruppe bei der ISO, bzw. Office Open XML lesen. Wirklich positive Berichte kommen dabei – außer bei Microsofts Vertragspartnern – aber nicht vor. Was liest man zusammenfassend hier und dort über OOXML?

1. Nicht vollständig implementierbar
2. Nicht interoperabel
3. Nicht barrierearm
4. Nicht vollständig konvertierbar
5. Inkonsistent
6. Erfindet viele Räder neu
7. Fehlerhaft
8. Nicht händisch veränderbar
9. Schwammig formuliert
10. Nur für Microsoft Office geschaffen

Nicht vollständig implementierbar

Es ist für Nicht-Microsoft-Programmierer praktisch unmöglich, die Spezifikation vollständig umzusetzen. Der Umfang der Dokumentation mit seinen 6.000 Seiten erschlägt einen mit Arbeit. Alter Ballast aus vorigen proprietären Microsoft-Dateiformaten ist in die neue Spezifikation undokumentiert übernommen worden und lässt einen im Ungewissen, was beispielsweise autoSpaceLikeWord95 oder truncateFontHeightsLikeWP6 bedeuten soll. Bezugnahmen auf proprietäre Technologien wie Windows Meta File Format, Microsoft-spezifische Namensräume oder Abhängigkeiten zu bestimmten Versionen des Internet Explorers machen die Spezifikation Windows-lastig und nicht mehr unabhängig, offen und frei dokumentiert. (Unter anderem die PDF-Datei des dänischen Normungsinstituts zum Thema DIS 29500 zeigt eine ganze Reihe solcher Mängel auf.)

Nicht interoperabel

Mit Interoperabilität meint Microsoft die (exklusive) Zusammenarbeit mit älteren Microsoft Office-Formaten und nicht die eigentliche Bedeutung von Interoperabilität, nämlich den Austausch von Information zwischen verschiedenen Anwendungen und Formaten ohne Einschränkungen. Da zudem in den OOXML-Endnutzerverträgen das Reverse Engineering alter MS Office-Formate untersagt wird, wird eine vollständige Implementation der Spezifikation (die in Teilen auf undokumentierten, alten MS-Technologien aufbaut und ein Reverse Engineering notwendig macht) und die Interoperabilität anderer Programme mit Microsoft Office verhindert. (Siehe dazu Kommentare von Fachanwalt Michael Schinagl von der Kanzlei BDHSW auf heise.de.) Unflexible Nummernsysteme machen OOML zudem inkompatibel mit einigen regionalen Nummernsystemen und sie widersprechen denen von W3C XSLT und Unicode ISO 10646.

Nicht barrierearm

Das Adaptive Technology Resource Centre der Faculty of Information Studies der Universität von Toronto hat ein detailliertes Papier herausgegeben, das die Zugänglichkeit von OOXML für benachteiligte Personen bezweifelt. Siehe dazu den Artikel Accessibility Issues with Office Open XML und den vollen Bericht des ATRC.

Nicht vollständig konvertierbar

Es ist nicht so einfach wie bei OpenDocument möglich, Konvertierungswerkzeuge für OOXML zu bauen. Die einfachste Art, Konverter für Daten mit XML-Strukturen zu bauen, ist mittels XSLT-Transformatoren. Doch OOXML unterstützt die dafür notwendige Technologie XPath nicht vollständig fehlt es an der nötigen „XPath-perfekten” XML-Struktur, damit XSLT reibungslos funktioniert, weshalb der XSLT-Transformator von Microsoft/Clever-Age/Novell schlicht unzureichend arbeitet.

Inkonsistent

In weiten Teilen der Spezifikation wird immer noch das veraltete VML anstatt des neueren DrawingML benutzt, obwohl es in der Spezifikation selbst als veraltet/misbilligt beschrieben wird. Noch dazu besitzt DrawingML nicht alle Möglichkeiten von VML, weshalb VML nicht nur zum Zweck der Abwärtskompatibilität in OOXML weiterhin gebraucht wird. Auch Textformatierungen sind inkonsistent aufgebaut, da sie je nach Office-Programm (Word, Excel, PowerPoint) verschiedene Bezeichnungen haben. In OpenDocument (ODF) dagegen sind Formatierungen immer gleich, egal in welchem Programmteil Text verwendet wird. Sogar Prozentangaben werden auf verschiedene Weise inkonsistent in OOXML dargestellt.

Erfindet viele Räder neu

Anstatt bestehende und bewährte Technologien und Normen zu verwenden, erfindet Microsoft in OOXML vieles unnötig neu und verkompliziert so die Implementierung und die Lesbarkeit der Spezifikation. Statt VML/DrawingML könnte SVG genutzt werden. Statt der eigenen Papiergrößen-Bezeichnungen wäre ISO 216 zu bevorzugen. Statt der unleserlichen Zahlenkolonnen in OOXML müsste ISO 8601 verwendet werden, um Datum und Zeit abzuspeichern. Der OOXML-eigene Hash-Algorithmus sollte zugunsten bestehender und bewährter (wie zum Beispiel von FIPS 180) als missbilligt deklariert werden. Statt eigens erfundener Farbbezeichnungen sollten das SVG- oder ISO/IEC 15445-HTML-Farbschema übernommen werden. Sprach- und Ländercodes nach ISO 639 würde jeder verstehen statt der OOXML-eigenen Codes. Auch bei Graphics Metafiles geht OOXML einen eigenen Weg, anstatt ISO 8632 zu nutzen.

Fehlerhaft

Alter Microsoft-Ballast macht OOXML nicht nur nicht vollständig implementierbar, sondern normt auch alte Microsoft-Programmierfehler und nimmt sie so mit weit ins 21. Jahrhundert hinein. Das krasseste Beispiel dafür ist die Missachtung des gregorianischen Kalenders beim Arbeiten mit Kalenderdaten, wo das Jahr 1900 fälschlich als Schaltjahr gerechnet wird, was auch Konsequenzen beim Datenaustausch mit anderen Programmen hat. Sicherheitskritisch ist die Tatsache, dass man eine passwortgeschützte Excel-Tabelle wieder beschreibbar machen kann, indem man einfach das Element sheetProtection mit einem Texteditor aus dem OOXML-Code entfernt.

Nicht händisch veränderbar

Einer der wichtigsten Vorteile von gepackten XML-Daten, nämlich dass man sie per Hand mit einem Texteditor nachbearbeiten kann, trifft auf OOXML nicht zu. Excel-Kalkulationen kann man nicht so einfach nachträglich per Texteditor ändern. Denn viele Abhängigkeiten zwischen verschiedensten OOXML-Teilen machen eine klitzekleine Änderung zum Spießrutenlauf und im schlimmsten Fall (und das geht schnell) wird das Dokument für Excel unbrauchbar. Stéphane Rodriguez hat dies nachgewiesen. Eignet sich so ein Format, das per Texteditor ohne detaillierte Kenntnisse zum Dateiformat selbst nicht leicht zu ändern ist, als Speicherformat zur Langzeitarchivierung von Daten (zum Beispiel wenn kein geeignetes Programm mehr zum Verarbeiten des Dokuments vorhanden ist)?
Noch ein Vorteil von XML ist die leichte Lesbarkeit der Elemente und Attribute für Mensch und Maschine gleichermaßen. OOXML ist aber mit seinen Elementen wie scrgbClr oder rPr weder konsistent noch für Menschen lesbar gestaltet.

Schwammig formuliert

Verweise auf bestimmte Versionen von Normen und Spezifikationen (Unicode, EMF, WMF, XML, XML Schema, XPath, XSL, ZIP, ASCII Characters, …) fehlen, was viele verschiedene, zueinander inkompatible Implementierungen zur Folge haben wird. Oder anderes Beispiel: Mehrere Financial Functions verweisen auf eine „day count basis”, die nicht näher beschrieben ist.

Nur für Microsoft Office geschaffen

Die Marketingmasche mit open by design kommt spätestens dann jedem unglaubwürdig vor, wenn man weiß, wann Microsoft OOXML öffentlich zugänglich gemacht hat: Nämlich erst als MS erkannte, dass sich mit OpenDocument (ODF) von der OASIS ein offenes Dokumentenformat erfolgreich und unaufhaltsam (langsam aber stetig) seinen Weg durch Normungsgesellschaften, Behörden und die OpenSource-Gemeinschaft bahnt. Um dem fortschreitenden Erfolg von ODF entgegen zu wirken, wurde OOXML veröffentlicht und mit dem Prädikat „offen” versehen, dann der ECMA vorgelegt, die es ohne eingehende Begutachtung oder Änderungen als ECMA 376 akzeptiert hat, und dann zur ISO weitergeleitet.

Und ist OOXML schon vorher als offen konzipiert worden? Dinesh Nair vom Open Malaysia-Blog war beim Microsoft Summit 2007 und hat von einem Microsoft-Manager die technische Wahrheit über OOXML erfahren: … the file format (OOXML) was a part of the software and that OOXML and the software (MS Office) are quite inseparable. Ergo, OOXML is an integral and inseparable part of MS Office. That’s why they could not adopt ODF as the file format for subsequent versions of MS Office. … (Zitat aus Open Malaysia) Mit so einer Aussage eines Microsoft-Insiders müssten sich eigentlich alle weiteren Bemühungen der ISO erledigen. Soll ein Dateiformat, das von einer einzigen Firma speziell für ein einziges Produkt entworfen wurde und von ihm nicht zu trennen ist, als internationale Norm verabschiedet werden?

Zudem existiert noch keine einzige ECMA 376-Implementation. (ECMA 376 entspricht DIS 29500 bei der ISO.) OOXML von MS Office 2007 weicht vielerorts von ECMA 376 ab, weshalb davon auszugehen ist, dass ECMA 376 bzw. DIS 29500 nicht ausreichend ist, um andere Programme mit MS Office 2007 vollständig kompatibel zu machen.

Update 2007-09-18: Am 10. September 2007 wird Brian Jones von Microsoft bei computerworld.com mit den Worten zitiert: It’s hard for Microsoft to commit to what comes out of Ecma in the coming years, because we don’t know what direction they will take the formats. We’ll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day, though, the other Ecma members could decide to take the spec in a completely different direction. … Since it’s not guaranteed, it would be hard for us to make any sort of official statement. Man darf sich also nicht darauf verlassen, dass Microsofts OOXML-Weiterentwicklungen die selben sein werden wie die der Ecma – geschweige denn der ISO.

Diese Informationen sind aus unzähligen Quellen seit Monaten zusammengetragen und wurden noch nicht durch technische Beweise entkräftet. Einige besonders umfangreiche Quellen sind die dänische Normungsorganisation DS mit ihrer 64-seitigen Kritik, Heise in diversen Artikeln (als kurze Zusammenfassung diverser Veröffentlichungen meist gut zu lesen) wie dem über juristische Unklarheiten und restriktive Endnutzerverträge, Stéphane Rodriguez mit seinen erschreckenden, fundierten technischen Analysen von OOXML mit MS Office 2007, das Technical Distinctions of ODF XML and OOXML-Dokument der ODF Alliance European Action Group sowie die lange Liste der EOOXML objections von grokdoc.net.

Persönlich finde ich es sehr unwahrscheinlich, dass Microsoft alle technischen Mängel, wie sie von den nationalen Normenorganisationen vorgelegt wurden, abarbeiten und in DIS 29500 umsetzen wird. Erstens wären das ein enormer Arbeitsaufwand (allein schon wegen VML und DrawingML), der nicht in wenigen Wochen oder Monaten zu bewerkstelligen ist, ohne dass sich Fehler und Schlampereien einschleichen. Zweitens wäre das ein Eingeständnis seitens Microsoft, dass die Gegner von OOXML recht hätten und diese Spezifikation wirklich qualitativ zu schlecht und überarbeitungswürdig sei. Drittens müsste MS Office 2007 dem überarbeiteten DIS 29500 angepasst werden, sonst kommt es zu Inkompatibilitäten zwischen MS-eigenen OOXML-Dateien und jenen aller anderen. – Von den nichttechnischen Mängeln wie Patente ganz abgesehen, die bei der ISO sowieso nur unzureichend behandelt werden.

Update 2007-09-18: Abschnitt Nur für Microsoft Office geschaffen erweitert.