Seit OpenDocument 1.1 im Frühjahr bei der OASIS als offizielles Dokument verabschiedet worden ist, habe ich die Mailinglisten der ODF-Macher verfolgt und bin etwas kritischer geworden, was die Entwicklung der Interoperabilität von ODF angeht.

Was ist Interoperabilität?
Das ist im Falle von ODF die Möglichkeit, verschiedene Programme zum Erstellen, Bearbeiten und Speichern von Dokumenten zu benutzen und nicht angewiesen zu sein auf ein bestimmtes Programm.
Wie schafft man Interoperabilität bei einem Dateiformat?
Wenn bei der (Weiter-)Entwicklung von ODF 1. die Unabhängigkeit von bestimmten Programmen und Firmen gewährleistet ist und 2. möglichst viele daran mitwirken (Einzelpersonen, Firmen, Organisationen und Behörden).

Der 1. Punkt ist durch die OASIS eigentlich gegeben, aber Sun Microsystems spielt immer noch die bestimmend(st)e Rolle bei der Weiterentwicklung von ODF (welches ein Ableger ihres älteren OpenOffice.org 1.0-Dateiformats darstellt). Punkt 2 mag ebenfalls durch die OASIS abgedeckt sein, da jedes OASIS-Mitglied sich an der Entwicklung beteiligen, Vorschläge einbringen und mitdiskutieren kann. Und jede Firma kann OASIS-Mitglied werden. Aber die Materie ist komplex und nur wenige Personen haben das Wissen, eine umfangreiche Spezifikation wie ODF (mitsamt den damit verknüpften Techniken XML, RDF, SVG, …) zu verstehen und daran mitzuwirken. Wenn man die offiziellen Mailinglisten verfolgt, so sieht man großteils nur wenige Personen weniger Firmen wie Sun, IBM, Novell, Trolltech/KDE.

Gut, diese Gegebenheiten sind an sich nichts Schlechtes. Zu viele Köche verderben den Brei. Sun fördert aktiv die Weiterentwicklung von ODF. IBM leistet zum Beispiel mit Robert Weir hervorragende Arbeit bei der Ausarbeitung der Spezifikation für Formeln/Tabellenkalkulationen, die in seiner vollständigen Form erstmals offiziell Teil von OpenDocument in Version 1.2 sein wird. Außerdem beruhigt die Anwesenheit von KDE-Entwicklern, die die reibungslose Zusammenarbeit mit Linux-Umgebungen und eine zweite (vollständige) Referenz-Implementierung von ODF, nämlich in KOffice, sicherstellen.

Aber jede dieser Firmen hat natürlicherweise Eigeninteressen, die es auch innerhalb der OASIS-Spezifikation gewahrt wissen will. Zwei Beispiele: Sun will ODF weiterhin abgrenzen gegen Microsofts OOXML. Die OpenDocument-Foundation will ODF zu einem wahren Austauschformat machen und fast perfekte Wiedergabetreue (perfect fidelity) und Interoperabilität (interoperability) erreichen, um Dateikonvertierungen von und zu ODF (speziell mit Microsofts OOXML und DOC/XLS/PPT) reibungsloser als bisher zu ermöglichen.

Hürden für Interoperabilität

Die im vorigen Absatz angeschnittenen Eigeninteressen der ODF-Macher (die legitim sind) schaden OpenDocument bei der Verbreitung mehr als sie helfen, zumindest quantitativ gesehen. Sun möchte natürlich seinen OpenOffice.org-Ableger StarOffice an den Mann bringen und das kostenlose OpenOffice.org weiter verbreiten. Das geht aber nur, wenn es sich abgrenzt von MS Office und der Dateiaustausch nur beim Import reibungslos funktioniert, OpenDocument aber nicht als verlustfreies Austauschformat zwischen Suns Office und MS Office dient. Denn dann könnte ja jeder bei MS Office bleiben und trotzdem OpenDocument verwenden. (In die gleiche Kerbe schlägt Sun mit der Planung, nur einen OOXML-Importfilter für OpenOffice.org 3.0 zu entwickeln und keinen gleichwertigen Exportfilter.)

Das Interesse der OpenDocument-Foundation ist vorhin schon skizziert worden: ODF als verlustfreies Austauschformat zwischen verschiedenen Programmen. Das widerspricht natürlich dem Wunsch von Sun (als Ganzes; persönliche Interessen von Suns Mitarbeitern kenne ich nicht) bezüglich OpenOffice.org. Reibungslose Interoperabilität ist aber nur gewährleistet, wenn Programme Daten aus ODF-Dateien verlustfrei importieren und exportieren können.

Interoperabilität besitzt noch nicht die nötige Priorität in den OpenDocument- Arbeitsgruppen, weshalb ODF noch nicht wirklich und nachdrücklich zum Durchbruch verholfen werden konnte. Die Verantwortung für Interoperabilität wird eher auf die Software-Ebene geschoben als sich damit innerhalb der ODF-Spezifikation genauer zu befassen. Fakten gefällig?

  1. Florian Reuter machte in seinem Blog im November 2006 eine Auflistung von Anpassungen, die ODF 1.2 seiner Meinung nach benötigen könnte und die Zusammenarbeit mit MS Office-Dateiformaten erleichtern sollten. (Er ist Mitarbeiter von Novell, und Novell hat mit Microsoft einen Pakt geschlossen, Konverter für OOXML<>ODF zu programmieren.) Praktisch nichts davon wurde in der Arbeitsgruppe aufgegriffen, wie er vor kurzem erläuterte.
    In der Mailingliste wurde ein abweisender Kommentar dazu abgegeben. Kurz umrissen: Man werde ODF nicht verändern, nur um mit Funktionen von MS Office-Dateiformaten besser umgehen zu können, für die es in ODF noch keine Entsprechung gibt. Und die Bemerkung, man solle seitens Novell doch ein paar Änderungen am Microsoftschen OOXML-Format vorschlagen, klingt zynisch, da doch jeder in der Mailingliste weiß, dass Microsoft niemals sein Format wegen äußerer Vorschläge ändern wird. Der abweisende Kommentar kam von Sun, und man kann aus Suns Sicht verstehen, dass in OpenDocument nichts stehen soll, was es nicht auch in OpenOffice.org gibt (man könnte ja später von Sun fordern, diese ODF-Funktionen auch in OpenOffice.org einzubauen). Diese Abwehrhaltung widerspricht aber dem Gedanken von OpenDocument als anwendungsunabhängiges Dateiformat. Zusätzlich hilft diese Abwehrhaltung auch nicht, ODF als Austauschformat bei Behörden durchzusetzen, da es der ODF-Arbeitsgruppe offensichtlich am Willen fehlt, auch Fremdprodukte zu unterstützen und eine reibungslose Konvertierung zu ermöglichen. (Darum das Versagen in Massachusetts, siehe nächster Punkt.)
  2. Die IT-Abteilung der Verwaltung von Massachusetts plante 2006 den Umstieg auf OpenDocument (nicht auf OpenOffice.org/StarOffice) mithilfe von daVinci/InfoSet. Die Bemühungen von Massachusetts scheiterten aber unter anderem an den Anpassungen, die an OpenDocument hätten vorgenommen werden müssen, um den schon angesprochenen reibungslosen Austausch zwischen ODF und anderen Dateiformaten (in beide Richtungen!) zu gewährleisten. Gary Edwards schrieb dazu einen Kommentar auf meine Frage hin, ob es denn einen Zeitplan für die Fertigstellung von daVinci gäbe.
    Aufgrund der fehlenden, von der ODF-Arbeitsgruppe nicht aufgegriffenen Anpassungen von ODF, ohne die es keine reibungslose Konvertierung geben kann, wurde in Massachusetts (wie auch in anderen US-Bundesstaaten und Dänemark) entschieden, dass auch OOXML als offiziell anerkanntes Dateiformat gelten darf. Somit hat ODF die wichtige Unterstützung von Behörden verloren, die zur Verbreitung und öffentlichen Akzeptanz von ODF geführt hätten.
    Ich frage mich persönlich, wie dies Sun als gewinnträchtige Firma hilft in seiner Verbreitung von StarOffice, wenn ODF in Zukunft nicht mehr in Betracht gezogen wird, weil es sich nicht gut genug in den täglichen Arbeitsprozess von Behörden/Firmen einfügen lässt.
  3. Die allgemeine Ablehnung gegen Anpassungen von ODF hinsichtlich Kompatibilität zu MS Office/OOXML mag auch mit einer Abstimmung zusammenhängen, bei der IBM und andere dagegen stimmten, Konformität von ODF mit einem Format einer einzelnen Firma herzustellen (erwähnt in einem Archiv-Kommentar). Das hört sich eigentlich vernünftig und nach einem hehren Ziel an. Zumindest für weniger verbreitete Produkte; es gäbe auch zu viele davon, um alle zu berücksichtigen. Aber wenn die Mehrheit der weltweiten Anwender von Büro-Software Funktionen nutzt, die in ODF nicht implementiert sind oder nicht verlustfrei umgewandelt oder zumindest erhalten werden können (für einen späteren Export aus ODF heraus und deren Wiederverwendbarkeit), wieso sollten diese dann umsteigen auf ODF, wenn ihre Dateien dadurch Schaden nehmen oder aufwändig nachbearbeitet werden müssen?
  4. Interoperabilität mit anderen ODF-Programmen und anderen Dateiformaten wie OOXML und UOF scheint auf ODF nach Version 1.2 hinausgeschoben zu werden, wie hier, hier und hier (letzter Absatz zu ODF 1.3) als Beispiel nachzulesen ist. Doch kann es sein, dass alle Behörden und Firmen schon auf OOXML umgestiegen sein werden, bevor ODF 1.3 im Jahr 2008 oder 2009 das Licht der Welt erblickt.
  5. David A. Wheeler, der Vorsitzende der ODF-Unterarbeitsgruppe für Formeln/Tabellenkalkulation hat in einem Kommentar angeregt, die Liste der unzureichenden oder fehlenden Funktionen der beiden Dateiformate des ODF-Konverters von Microsoft durchzugehen und auf Fehler im Konverter und möglicherweise neu in ODF (oder OpenOffice.org) zu implementierende Funktionen zu prüfen. (Nebenbei erwähnt Wheeler noch, untermauert durch Beispiele, dass OOXML laut dieser Liste viel eingeschränkter sei als ODF. – Im Frühjahr, als ich mir die Websites des ODF-Konverters von Microsoft angesehen habe, kam mir auch schon der Gedanke, dass diese Liste eine perfekte und schnelle Vorlage wäre für Anpassungen von ODF oder OpenOffice.org.) Aber leider: Analog zur Ablehnung in den vorherigen Beispielen gab es auch hier keine einzige Reaktion dazu in der Arbeitsgruppe und keine weiteren Schritte hin zu einem besseren Universaldateiformat.
  6. Apropos Universaldateiformat: Sun möchte gewährleisten, dass OpenDocument von möglichst vielen unterschiedlichen Anwendungen korrekt nach den Vorgaben der Spezifikation verwendet werden kann. Das heißt natürlich, dass es so wenig wie mögliche Vorgaben, Einschränkungen oder Beschränkungen geben darf, damit ja möglichst viele Anwendungen alles implementieren können, nicht nur Office-Programme. Die Folge: Alle Absätze in der Spezifikation, bei denen es um bestimmte Elemente, fremde Inhalte („alien elements”) oder Metadaten geht, die man für die Interoperabilität mit anderen Programmen bewahren müsste, werden schwammig oder locker formuliert. Zum Beispiel darf ein Programm alle Metadaten löschen und ist trotzdem konform mit der Spezifikation (in Folge davon fehlen einem anderen Programm, mit dem man die Datei weiterverarbeiten will, wichtige Daten).
    Ein Dokument, in dem eine Reihe von zuvor noch vorhandenen Vorgaben für Software-Hersteller aus ODF gelöscht werden, ist das OpenDocument 1.2 File Format Change Proposal – Issues List Metadata Model vom 3. Juli 2007. Man lese selbst Abschnitt 1.20, 1.22 und 1.23.

Mehrere Konformitätskriterien

Marbux, ein Mitglied der ODF-Mailingliste, hat in einem Beitrag vorgeschlagen: Wenn man denn schon eine sehr offene Dokumentennorm haben will, solle man zwei Konformitätskriterien erstellen; eines für Softwareentwickler, die ihre Programme für die Einweg-Verarbeitung von ODF-Dateien optimieren (also nur für den Import oder Export von OpenDocument-Daten, sinnvoll zum Beispiel für Grafik- oder Desktop-Publishing-Programme wie Inkscape oder Scribus), und eines für jene, die ihre Programme für den Import und Export optimieren und einen möglichst verlustfreien Austausch von Daten gewährleisten wollen. (Office-Pakete passen klassischerweise zu zweiterem, da sie nicht der Abschluss eines Bearbeitungsprozesses sind und Daten danach nicht endgültig archiviert, sondern woanders weiterverarbeitet werden.)

Es steht außer Frage, dass die Vorgaben, dass bestimmte oder ODF-fremde Inhalte und Metadaten nicht gelöscht werden/bewahrt werden sollen, näherer Klärung bedürfen (wann darf es doch geschehen, was bedeutet es für Software-Hersteller genau usw.). Mehrere ODF-Arbeitsgruppenmitglieder stehen strikteren Vorgaben aus diesen technischen Überlegungen entgegen, wie zum Beispiel Robert Weir in einem Mailinglisten-Beitrag schreibt.

Auch andernorts gibt es heftige Diskussionen, z.B. bei ODF-Fellowship, ob es überhaupt wünschenswert sei, Microsofts fremde Elemente in ODF unterzubringen und damit perfekte Wiedergabetreue zu gewährleisten. Dazu wurde von Daniel Carrera vorgeschlagen, die ODF-fremden Elemente von Microsofts OOXML in OOXML-Form einzubinden und nicht in kryptischer Binärform. Eine ODF-Datei wäre immer noch konform der Spezifikation, auch wenn sie OOXML-Elemente beinhaltet.

Damit ODF nicht ein ähnliches Schicksal wie TIFF erleidet und durch Erweiterungen bestimmter Programme/Firmen nicht selbst inkompatibel/inoperabel wird, muss unter anderem das Einbinden fremder Elemente auf jene beschränkt werden, für die es keine Entsprechung in der ODF-Spezifikation gibt, wie Daniel Carrera vorgeschlagen hat. Dazu müsste aber in Abschnitt 1.5 der Spezifikation das Wörtchen SHOULD in MUST NOT geändert werden: „There are no rules regarding the elements and attributes that actually
have to be supported by conforming applications, except that
applications should not use foreign elements and attributes for features
by the OpenDocument schema. See also appendix D.”
– Auch andere Abschnitte der ODF-Spezifikation müssten wohl strenger geregelt werden, um ein Inkompatibelwerden von ODF zu unterbinden.

Wie auch immer es ausgeführt werden kann/soll: Als Konsens sollte die Grundrichtung stimmen, dass ein Dokumentenformat mit den hohen Ansprüchen wie OpenDocument bessere Interoperabilität mit verbreiteten Dateiformaten gewährleistet, als es bis heute der Fall ist. Wie auch immer das möglich wäre – und wie auch immer das möglichst rasch möglich wäre mit schnell zu entwickelnden Werkzeugen, um den Markt dafür zu decken.

Software-Ebene oder Dokumentenebene?

Eine weitere berechtigte Frage ist, ob man solche Konformitätskriterien oder striktere Vorgaben überhaupt in einer Spezifikation unterbringen oder ob man diese eher den Software-Herstellern überlassen soll. Office-Hersteller mögen sicherlich Zweiteres bevorzugen und sagen, lasst doch den Markt entscheiden; niemand lässt sich schließlich gern etwas vorschreiben. Aber wie so oft bringt es der Mehrheit der Anwender mehr, wenn gewisse Spielregeln vorgegeben werden, damit nicht bestimmte Gruppen bevorzugt werden oder egoistische Wünsche auszuleben überhand nimmt. Mit verschiedenen Konformitätskriterien wären Vorgaben besser in der Spezifikation untergebracht als sie dem guten Willen der Software-Hersteller auszuliefern. Damit wäre Interoperabilität auch objektiv überprüf- und bewertbar. Der Acid2-Test hat der Browser-Landschaft erst die nötige Unterstützung für wichtige Teile der CSS-Spezifikationen abgerungen. Das selbe wird für ein interoperables ODF nötig sein.

Kommt die Interoperabilitäts-Arbeitsgruppe?

Am 6. Mai 2007 stellte Robert Weir von IBM die Frage einer künftigen Interoperabilitäts-Arbeitsgruppe nach der Verabschiedung von ODF 1.2. Besonders die UOF-Arbeitsgruppe, die sich mit der Zusammenarbeit/Konvertierbarkeit von ODF und der chinesischen Dokumentennorm UOF beschäftigt, interessiert sich sehr für mehr Interoperabilität. Dies macht Hoffnung für ODF 1.3, aber wie schon gesagt: Dann könnte der Zug für OpenDocument schon abgefahren sein.

Was könnte diese Arbeitsgruppe tun?

  1. Interoperabilität zwischen ODF-Anwendungen, egal ob es sich um traditionelle Programme wie OpenOffice.org, KOffice usw. oder um webbasierte Editoren wie Google Docs & Spreadsheets handelt.
  2. Interoperabilität zwischen ODF und anderen Markup-Sprachen wie MathML, XForms usw.
  3. Interoperabilität zwischen ODF und anderen hochspezialisierten Dokumentformaten wie DocBook, DITA oder UOML.
  4. Praktische Vorschläge für die Interoperabilität zwischen ODF und Mikroformaten wie vCard oder Creative Commons-Lizensierung .
  5. Interoperabilität zwischen ODF und anderen Dokumentformaten von Microsoft, Corel, Lotus usw.

Und was hat das mit mir zu tun?

Nun, ich will das, was wahrscheinlich die allermeisten Kunden möchten (und ich gehe davon aus, dass ich hier wirklich den Wunsch der Mehrheit aller Office-Anwender ausdrücke): Nicht daran denken zu müssen, welches Dateiformat sie benutzen. Wenn ich in meiner Firma ODF als Standarddateiformat durchsetzen will, darf es für Anwender nicht sichtbar werden, dass sie eine Datei anders abspeichern als vorher. Technisches und Ideologisches interessiert die Leute nicht. Es muss egal sein, ob sie Microsoft Office, Lotus Notes oder OpenOffice.org verwenden – es darf beim Speichern und Öffnen von OpenDocument-Dateien keine Rolle spielen.

Doch es spielt derzeit noch eine Rolle, mit welchem Programm man arbeitet. Sogar zwischen OpenOffice.org und KOffice gibt es Inkompatibilitäten, die erst noch aus dem Weg geräumt werden müssen, also zwischen zwei Programmen, die ODF als Standarddateiformat implementiert haben.

Keine Zweifel

Doch neben all meiner Kritik möchte ich keine Zweifel darüber aufkommen lassen: OpenDocument ist offener, zugänglicher, flexibler, unabhängiger und einfacher als das Konkurrenzformat OOXML, das derzeit bei der ISO diskutiert wird. Wer seine Daten hersteller- und betriebssystemunabhängig und zukunftssicher zur Weiterverarbeitung speichern will, kommt an ODF im Bereich Büro-Software nicht vorbei. Da mögen Werbekampagnen, FUD und Lobbyarbeiten der Konkurrenz noch so viel Gegenteiliges in die Welt setzen.

OpenDocument 1.0 war der Grundstein und die gemeinsame Basis aller beteiligten Parteien. OpenDocument 1.1 legte seinen Fokus auf Zugänglichkeit. OpenDocument 1.2 wird Formeln/Tabellenkalkulationen und Metadaten-Angaben perfektionieren sowie viele kleine Verbesserungen bringen wie Tabellen in Präsentationen und standardisierte digitale Signaturen. Wenn Hersteller von ODF-fähigen Programmen in Zukunft vermehrt auf Interoperabilität schauen (und zum Beispiel OpenOffice.org beim Importieren keine Metadaten und ihm fremde Elemente löscht), müssten wir nicht mal mehr auf OpenDocument 1.3 warten, dessen größte Aufmerksamkeit hoffentlich der Interoperabilität gilt.

Das Adaptive Technology Resource Centre der Faculty of Information Studies der Universität von Toronto hat ein detailliertes Papier herausgegeben, das die Zugänglichkeit mit dem Dateiformat OOXML behandelt.

Wofür steht das ATRC?

… The ATRC supports open standards …
We are strong advocates of the overlooked principle that people with disabilities should be producers and not only consumers of information, knowledge and culture. …

Welchen Schluss zieht das ATRC bezüglich OOXML?

There are grave issues with respect to the accessibility of Office Open XML as a format and potential standard that should preclude its adoption at present. It may be the case that OOXML can be improved to ameliorate some of the more specific technical concerns, but it is most likely too late for the higher-level issues, especially those inherent in the process by which OOXML was developed. We suggest that energy would be better spent in the ongoing effort to improve the existing ISO ODF standard (with which OOXML would overlap and compete if it is adopted). In any event, decisions with respect to standardized document formats should be made in consultation with members of disability communities, disabilities experts and developers of assistive technologies, with universal accessibility as a core requirement as opposed to an ad hoc afterthought.

Der volle Bericht ist hier nachzulesen:
Accessibility Issues with Office Open XML vom 07. August 2007.

Die letzte Version OpenOffice.org 2.2.1 hat nur Fehler bereinigt aber sonst keine Neuerungen/Verbesserungen gebracht. Mit der nächsten Version 2.3 ist dies anders. 42 neue Funktionen und 212 Fehlerbereinigungen oder Funktionsverbesserungen wurden die letzten Monate eingebaut. (Die OOo-Wiki-Seiten Feature Freeze Testing 2.3 und die New Features 2.3 geben detailliertere Auskunft über die eingebauten Veränderungen.)

Die Fülle an verschiedensten Verbesserungen und Neuerungen zeigt, dass das Konzept aufgeht, alle 6 Monate eine neue x.y-Version zu veröffentlichen und zwischendurch alle 3 Monate ein x.y.z-Bugfix-Release (ohne Neuerungen). Für OpenOffice.org 2.4 sind auch einige Dinge in Planung, wie man zum Beispiel auf Seiten wie der OOo-Wiki-Seite Features (für die großen Projekte) oder der OOo-Wiki-Seite Calc Usability Activities (Verbesserungen der Benutzerfreundlichkeit in Calc) nachlesen kann.

Wie man sieht, tut sich einiges in der OpenOffice.org-Gemeinschaft.

Und was tut sich Neues bei OOo 2.3?

Die Neuerungen mit dem Stichwort Benutzerfreundlichkeit sind dem Dokument Calc Usability Activities entnommen. Eine Erklärung dazu gibt es im GullFOSS-Blog.

Hoffentlich gibt es in Version 2.4 auch wieder viele Verbesserungen in Punkto Benutzerfreundlichkeit und wieder einige neue Funktionen (Notes2 wird davon die bedeutendste sein).

Erscheinen wird OpenOffice.org 2.3 im September 2007, Version 2.4 dann im Frühjahr 2008 auf de.openoffice.org.