Übersetzung: englisches Original von Italo Vignoli
Für jeden, der das Standardformat dem proprietären Format vorzieht, stellt sich natürlich die Frage: Warum verarbeiten Office-Suiten, die OOXML als natives Format verwenden, ODF auf eine Art und Weise, die von schlecht bis entsetzlich reicht?
Die zwei offensichtlichsten Antworten sind diese: Die Anbieter haben das Format vernachlässigt und als Nebensache behandelt, oder sie arbeiten stillschweigend daran, die Idee der transparenten Interoperabilität selbst zu diskreditieren, indem sie den Support so schlecht unterstützen, dass er zeigt, dass das Format „nicht funktioniert“.
Beide Antworten sind zu einfach. Die Realität ist, dass drei unterschiedliche Mechanismen am Werk sind, die in unterschiedlichem Ausmaß auf verschiedene Anbieter anwendbar sind und letztendlich zum gleichen Ergebnis führen.
Eine Herausforderung, die keine Herausforderung ist
Das originalgetreue Lesen und Schreiben von ODF – für sich genommen – ist durchaus machbar: Das Format ist vollständig und offen spezifiziert, und es gibt kein Äquivalent zu den berüchtigten Kompatibilitäts-Flags von OOXML, die sich auf undokumentierte Verhaltensweisen älterer Microsoft-Produkte beziehen, welche nur von Microsoft selbst reproduziert werden können.
Ein kompetentes Entwicklerteam ist in der Lage, ODF allein auf der Grundlage der ODF-Spezifikation korrekt zu implementieren.
Eine Office-Suite implementiert ein Format jedoch nicht isoliert: Sie verfügt über eine interne Repräsentation des Dokuments im Arbeitsspeicher. Das Laden eines Dokuments entspricht einer Überführung in diese Repräsentation, das Speichern einer Überführung aus ihr heraus.
Die Originaltreue ist am höchsten, wenn das interne Modell mit dem Dokumentformat übereinstimmt. Das Modell von LibreOffice basiert im Wesentlichen auf ODF; daher ist ODF in diesem Kontext das wahrhaft native Format.
Wenn das interne Modell einer Office-Suite auf OOXML basiert, verliert ODF seinen Status als natives Format und wird zu einem externen Import, der in eine für ein anderes Format konzipierte Darstellung umgewandelt werden muss – und umgekehrt.
Betrachten wir eine ODF-Funktion, die in OOXML fehlt: das ODP-Feld zur Anzeige der Gesamtzahl der Folien. Aufschlussreich ist dabei, dass die Information selbst in einer PPTX-Datei durchaus vorhanden ist. Das Paket listet jede Folie auf, und die Anzahl ist für jedes Programm verfügbar, das die Datei öffnet. Was OOXML jedoch nicht bietet, ist eine Möglichkeit, explizit festzulegen, dass es sich bei dieser Zahl um die Gesamtsumme handelt. Es gibt zwar ein Feld für die aktuelle Foliennummer, aber keines für die Gesamtzahl; Microsofts eigene Empfehlung lautet, die Zahl in ein Textfeld einzugeben und manuell zu aktualisieren – was im Grunde bedeutet, dass gar kein entsprechendes Feld existiert. Jede veröffentlichte Umgehungslösung besteht aus einem Makro oder Add-in, das die Zahl einmalig berechnet und als statischen Text ausgibt.
Wird also eine ODP-Datei mit einem solchen Feld in einem OOXML-basierten Editor geöffnet, gehen nicht die Daten verloren, sondern die Anweisung. Die Zahl bleibt erhalten. Die Information, dass sie berechnet wurde, geht jedoch verloren, und von diesem Moment an „weiß“ das Dokument nicht mehr, wie umfangreich es ist.
Der umgekehrte Weg scheitert auf unauffälligere – und damit fatalere – Weise. Eine von Impress nach PPTX exportierte Folienanzahl muss als statischer Text ausgegeben werden; die Präsentation ist also am Tag der Konvertierung korrekt, aber fehlerhaft, sobald eine Folie hinzugefügt oder entfernt wird. Eine Zahl, die nicht mehr dynamisch berechnet wird, aber dennoch plausibel erscheint, ist problematischer als eine sichtbare Lücke, da nichts im Dokument darauf hinweist, dass eine Überprüfung erforderlich ist.
Ein ODF-basierter Editor geht mit diesem umgekehrten Fall völlig anders um. Trifft er auf eine Funktion, die in einem Format vorhanden, im anderen jedoch nicht vorgesehen ist, so stellt er die entsprechenden Daten zurück, anstatt sie zu verwerfen, und stellt sie wieder her, sobald das Dokument in das OOXML-Format zurücküberführt wird. In LibreOffice trägt dieser Mechanismus einen Namen – „Grab Bag“ (Sammelbehälter) – und ist ein dokumentierter Bestandteil der Importfilter, nicht etwa ein bloßes Nebenprodukt der Funktionsweise.
Der Unterschied liegt nicht in der Qualität des Importfilters, sondern darin, dass die Architektur von Grund auf darauf ausgelegt wurde, die semantischen Informationen des jeweils anderen Formats zu bewahren.
Dies ist von Bedeutung, da es zeigt, dass die mangelhafte ODF-Unterstützung in OOXML-basierten Programmpaketen bereits durch die gewählte Architektur weitgehend vorgegeben ist – noch bevor überhaupt die Frage nach den Beweggründen des Anbieters aufkommt. Die Schwierigkeit ist also nicht absolut, sondern hängt von der Architektur ab, für die sich der Anbieter entschieden hat.
Drei Mechanismen
Erstens: die Entscheidung für ein Referenzformat. Manche Software-Suiten berücksichtigen ODF überhaupt nicht, da sie ihr Leistungsversprechen auf dem jeweils anderen Format aufgebaut haben.
OnlyOffice ist hierfür das deutlichste Beispiel: Die Suite wurde auf der Basis von OOXML entwickelt und wandelt alle anderen Formate in dieses Modell um; ODF ist somit konzeptbedingt lediglich ein Import- und Exportformat zweiter Klasse.
WPS Office wurde entwickelt, um docx-, xlsx- und pptx-Dateien originalgetreu zu öffnen. Die ODF-Funktionalität basiert auf einem Add-in aus Microsofts eigenem OpenXML-Projekt und wurde erst im Mai 2022 in die Anwendung integriert – und zwar als Konvertierungsschicht für ODF 1.1, also für die Standard-Revision von 2007. Damit war die Software bereits zum Zeitpunkt ihrer Veröffentlichung technisch um 15 Jahre veraltet.
Google Workspace folgt eher derselben Logik, als dass es eine Ausnahme darstellt. Das interne Modell basiert weder auf ODF noch auf OOXML, sondern auf einer proprietären Web-Darstellung; beide Formate werden über eine Konvertierungsschicht angebunden. Für die öffentliche Verwaltung ist die Konsequenz dieselbe: Der offene Standard dient lediglich als Exportziel, nicht aber als Grundlage für die interne Datenverarbeitung der Software.
Für diese Anbieter war ODF nie Teil der Strategie. Ihr Leistungsversprechen besteht darin, Microsoft-Dokumente auch ohne Microsoft Office zu öffnen und dabei eine korrekte Darstellung zu gewährleisten; die mangelhafte ODF-Unterstützung ist somit die direkte Folge dieser Strategie.
Zweitens: bewusste Unterinvestition. Dies ist wahrscheinlich ein Problem, das den gesamten Markt für Office-Software betrifft. Obwohl sich ODF korrekt einfacher und kostengünstiger implementieren lässt, sind dennoch Aufwand und Zeit für Entwicklung, Qualitätssicherung und Wartung erforderlich, um mit einem sich stetig weiterentwickelnden Standard Schritt zu halten.
Wenn die Nutzer eines Anbieters vorwiegend docx-Dateien austauschen, ist der zusätzliche geschäftliche Nutzen einer exzellenten ODF-Unterstützung praktisch gleich null; folglich wird ODF zunächst nur im absolut notwendigen Mindestumfang implementiert und anschließend stillschweigend vernachlässigt.
Die Auffassung, ODF-Unterstützung sei unerheblich, ist ihrerseits eine Folge der Marktbeherrschung durch ein einzelnes Unternehmen, und ihre Auswirkungen sind zweifacher Natur: Die Bindung an einen Anbieter (Lock-in-Effekt) wird zu einem Softwaremerkmal, das der Markt als völlig normal betrachtet, und ODF haftet der Ruf der Fehleranfälligkeit an – ein Image, das ganz ohne gezielte Kampagnen entstanden ist.
Drittens: bewusste Disqualifizierung. Dieser Mechanismus ist real und betrifft Microsoft selbst – konkret das Service Pack 2 für Office 2007. Die darin enthaltene ODF-Unterstützung versagte gleich in zwei entgegengesetzte Richtungen.
Beim Einlesen einer mit einer anderen Anwendung erstellten ODF-Tabellenkalkulation entfernte Excel stillschweigend die Formeln und behielt lediglich den letzten in der jeweiligen Zelle gespeicherten Wert bei; dies reduzierte das Dokument – wie Rob Weir es seinerzeit einschätzte – auf eine bloße „Zahlentabelle“ ohne die ursprüngliche Berechnungslogik. Beim Speichern bettete Excel Formeln in einen Namensraum ein, der weder dem von OpenOffice und anderen ODF-Anwendungen genutzten noch dem OOXML-Namensraum entsprach. Anwendungen, die den Namensraum überprüften, lehnten das Dokument rundweg ab; Anwendungen ohne diese Überprüfung zeigten eine beschädigte Datei an, in der weder die Formel noch der Wert korrekt dargestellt wurden.
Dies ist ein Paradebeispiel für eine Strategie zur Diskreditierung von Interoperabilität: Eine Formatvorgabe wird mit einer Implementierung erfüllt, die zwar auf dem Papier konform ist, aber offensichtlich fehlerhafte Dateien erzeugt – womit jedem Beobachter demonstriert wird, dass ODF in der Praxis nicht funktioniert.
Damals argumentierte Microsoft, der ODF-Standard definiere keine Tabellenkalkulationsformeln – diese seien erst mit ODF 1.2 hinzugekommen –, weshalb es keine Vorgabe gegeben habe, an der man sich hätte orientieren können. Dieses Argument hält einer Überprüfung durch Microsofts eigene Reaktion nicht stand. In einer öffentlichen Antwort an Weir stellte Microsoft-Evangelist Doug Mahugh die beiden Verhaltensweisen einander gegenüber: Konfrontiert mit derselben unbekannten Formelsyntax, behielt IBM Lotus Symphony das Formel-Markup bei, während Excel die zwischengespeicherten Werte bewahrte. Für keine der beiden Anwendungen gab es eine verbindliche Spezifikation. Doch nur eine verfügte über eine Architektur, die einen Platz für das bot, was sie nicht verstand.
Es ist aufschlussreich, zu betrachten, was Excel beibehielt. Nicht die Formel, sondern deren letztes Ergebnis – eine Reduktion, wie wir sie bereits bei der Folienanzahl in einer anderen Anwendung beobachtet haben. Ein durch OOXML geprägtes Modell bewahrt den Wert und verliert die Berechnung, die ihn hervorgebracht hat; ein Dokument, das auf seine letzten Ergebnisse reduziert ist, hat die Fähigkeit zur Selbstkorrektur eingebüßt.
Dieser Vorfall liegt siebzehn Jahre zurück, und man könnte ihn leicht als bloße Geschichte abtun. Heute erklärt Microsoft Office, ODF 1.4 zu unterstützen. Doch was sich verbessert hat, ist die formale Konformität, nicht die Architektur. Das interne Modell basiert weiterhin auf OOXML, und jedes ODF-Dokument, das dieses System durchläuft, ist nach wie vor das Ergebnis einer Übersetzung.
Die Synthese
Die mangelhafte ODF-Unterstützung ist kein technisches Urteil über das Format, sondern spiegelt die Struktur eines Marktes wider, der von der Dominanz eines einzigen Anbieters geprägt ist – eine Struktur, die nicht zufällig entstanden ist.
Für öffentliche Verwaltungen in Europa verschiebt dies die praktische Fragestellung: Die Interoperabilitätsprobleme, auf die sie bei der Umstellung auf den offenen Standard ODF stoßen, liegen nicht an ODF selbst – dieses ist voll ausgereift. Vielmehr belegen sie, dass die meisten verfügbaren Werkzeuge ursprünglich für das Format eines anderen Anbieters entwickelt wurden und dass jener Anbieter, der die Macht hätte, diese Situation zu ändern, sich wiederholt dagegen entschieden hat.
Der unzureichende Stand der ODF-Unterstützung am Markt ist kein Grund, bei der Einführung des Standards zu zögern; im Gegenteil: Er ist ein zwingender Grund, den Standard verbindlich vorzuschreiben – und zwar präzise.
Entscheidend für den Schutz der Dokumente einer öffentlichen Stelle und deren Souveränität darüber ist nicht, ob ODF unterstützt wird, sondern ob diese Unterstützung nativ erfolgt: Basiert das interne Modell der Software auf dem offenen Standard, oder ist dieser lediglich ein Fremdkörper in einem System, das eigentlich für ein anderes Format konzipiert wurde?
Das Dokumentenformat bildet die Grundlage für Verwaltungskontinuität und das öffentliche Gedächtnis. Die Wahl von Werkzeugen, für die der offene Standard nativ ist, stellt keine Entscheidung zwischen gleichwertigen Alternativen dar; es geht vielmehr um den Unterschied zwischen dem Besitz der eigenen Dokumente und der bloßen Anmietung des Zugangs zu ihnen bei demjenigen, der die Kontrolle über das Format ausübt, in dem sie tatsächlich verfasst sind.
