Ein technischer Einblick in ODF

Englisches Original by Italo Vignoli

Um diesen Artikel zu schreiben, habe ich die Grenzen meines technischen Wissens überschritten, das dem eines fortgeschrittenen Anwenders entspricht, der sich intensiv mit Standardformaten und ihren Eigenschaften beschäftigt hat, um zu verstehen, warum Standardformate – eine der Säulen der digitalen Souveränität – und proprietäre Formate – ihr Gegenteil und eines der größten Hindernisse für die digitale Souveränität – von den meisten PC-Nutzern nicht als Problem wahrgenommen werden, die weiterhin die proprietären Formate von Microsoft verwenden und den Zugriff und die Verfügbarkeit ihrer Inhalte in die Hände des US-Unternehmens legen.

Um dieses Problem zu beheben, werde ich versuchen, einige technische Merkmale des Open Document Format (ODF) so einfach wie möglich und ohne Fachjargon zu erklären (was Entwickler vielleicht schockieren mag, aber dieser Artikel richtet sich nicht an sie). Diese Merkmale machen das ODF zum Eckpfeiler eines offenen und herstellerunabhängigen Ökosystems für Office-Dokumente, das die digitalen Freiheiten aller Nutzer und die Kontrolle über ihre Inhalte schützt.

Ich werde zunächst erklären, wie man eine ODF-Datei entpackt, die nichts anderes ist als eine Reihe von XML-Dateien und anderen Dateien (für Bilder und Videos), die in einem ZIP-Ordner enthalten sind, um ihre internen Komponenten und insbesondere die Datei content.xml zu untersuchen, die den Hauptteil des Dokuments enthält (d. h. das geistige Eigentum des Benutzers).

Das Ziel besteht weniger darin, die Konformität (Einhaltung der Spezifikationen) und Interoperabilität (die Fähigkeit, Dateien konsistent zwischen Tools auszutauschen) zu bewerten, da diese Aspekte immer von Spezialisten behandelt werden, sondern vielmehr darin, die Vorteile des offenen und standardisierten Formats gegenüber dem geschlossenen und proprietären Format (das fälschlicherweise als Standard bezeichnet wird, da es von ISO/IEC unter Missachtung „ihrer” Definitionen von Standards genehmigt wurde) für den Benutzer zu verstehen.

Aus diesem Grund werde ich abschließend kurz auf die Eigenschaften des von Microsoft Office und Microsoft 365 verwendeten OOXML-Formats (Office Open XML) eingehen, um den Benutzern erneut die Risiken zu verdeutlichen, denen sie ausgesetzt sind, und den Schaden, den sie sich selbst und anderen Benutzern zufügen, wenn sie die Formate DOCX, XLSX und PPTX verwenden, sowie das „Geschenk”, das sie Microsoft machen, dem sie effektiv die Verwaltung und Zukunft ihrer Inhalte anvertrauen.

Analyse einer ODF-Datei

Nehmen Sie ein beliebiges Dokument, das Sie mit LibreOffice erstellt haben. Der Einfachheit halber empfehle ich, mit einem Textdokument zu beginnen, das mit LibreOffice Writer erstellt wurde und die Erweiterung ODT hat. Bevor Sie etwas anderes tun, duplizieren Sie die Datei, da ein Fehler im Verfahren sie unlesbar machen könnte, und verschieben Sie das Original in einen anderen Ordner.

Benennen Sie die Kopie um und ersetzen Sie die Erweiterung ODT durch die Erweiterung ZIP, ohne den Punkt zu löschen. Das Dateisymbol wird zu dem einer komprimierten Datei. Wenn es weiß oder leer wird, haben Sie etwas falsch gemacht oder den Punkt gelöscht. Überprüfen Sie alle Schritte, bis das Symbol zu dem einer komprimierten Datei wird.

Klicken Sie nun mit der rechten Maustaste auf das Symbol und wählen Sie „Entpacken“ oder „Erweitern“, um den Inhalt der komprimierten Datei in einen Ordner mit dem gleichen Namen wie die Datei ohne Erweiterung zu extrahieren.

Der Ordner enthält die folgenden Elemente:

• der Ordner „META-INF“, der die Datei „manifest.xml“ enthält
• der Ordner „Thumbnails“, der die Datei „thumbnail.png“ enthalten kann
• die Datei „content.xml“, die den Hauptteil des Dokuments enthält
• die Datei „styles.xml“, die die Stildefinitionen enthält
• die Datei „meta.xml“, die die Metadaten der Datei enthält (Autor, Erstellungsdatum, Datum der letzten Änderung usw.)
• die Datei „settings.xml“, die die Anwendungseinstellungen enthält

Jede XML-Datei innerhalb eines ODF-Dokuments muss dem RelaxNG-XML-Schema (REgular LAnguage for XML Next Generation) entsprechen, das 2001 und 2002 von OASIS entwickelt wurde und einfacher – und damit für nicht-technische Benutzer leichter zugänglich – ist als andere XML-Schemas. Die Verpackungsregeln sind in den OpenDocument Packaging-Spezifikationen definiert.

Zusätzlich zur Schema-Validierung muss es eine Reihe von Bedingungen erfüllen.

• Strukturelle Konformität: die Elemente der ZIP- und manifest.xml-Dateien.
• Funktionale Konformität: alle Standard- und optionalen Funktionen (Metadaten, Stile, Tabellen, Grafiken usw.).
• Formel Konformität: Tabellenkalkulationsformeln müssen mit der OpenFormula-Semantik kompatibel sein.
• Sicherheits Konformität: ODF-Profile, Verschlüsselung, digitale Signatur.

Die Datei manifest.xml im Ordner META-INF muss alle Dateien in der ZIP-Datei mit ihrem Medientyp auflisten:

<manifest:manifest xmlns:manifest=”urn:oasis:names:tc:opendocument:xmlns:manifest:1.0″>
     <manifest:file-entry manifest:full-path=”/” manifest:media-type=”application/vnd.oasis.opendocument.text”/>
     <manifest:file-entry manifest:full-path=”content.xml” manifest:media-type=”text/xml”/>
     <manifest:file-entry manifest:full-path=”styles.xml” manifest:media-type=”text/xml”/>
     <!– thumbnails, settings, etc. –>
</manifest:manifest>

Das einfache Weglassen einer Datei oder ein Fehler in der Beschreibung ihres Medientyps reicht aus, um die ODF-Datei strukturell nicht konform zu machen.

ODF: Die Bedeutung der Datei „content.xml“

Um die Vorteile eines offenen Standardformats wie ODF gegenüber einem proprietären Format, selbst einem theoretisch offenen wie OOXML, für den Benutzer zu verstehen, eine kurze Analyse der Datei „content.xml” von ODF-Dateien und ihres Äquivalents in OOXML-Dateien, das je nach Dateityp unterschiedlich ist (und dies allein ist ein Zeichen dafür, dass bei der Entwicklung von OOXML die Bedürfnisse der Benutzer überhaupt nicht berücksichtigt wurden, sondern der Fokus auf einer künstlichen Erhöhung der Komplexität lag), ausreichend.

Nehmen wir ein erstes Beispiel, das auf einem der berühmtesten Sätze der Weltliteratur basiert, nämlich „Sein oder Nichtsein, das ist hier die Frage“, ausgesprochen vom Protagonisten in William Shakespeares Hamlet.

Die Datei content.xml eines Textdokuments, das nur diesen Satz enthält, ist 32 Zeilen lang: Die ersten 18 Zeilen enthalten Verweise auf alle verwendeten Standards (wie X-Forms und MathML), listen die in den Dokumentstilen verwendeten Schriftarten auf und definieren die Stile (in diesem Fall nur einen, angesichts der Länge des Textes und der fehlenden Formatierung).

Die nächsten 13 Zeilen lauten wie folgt:

<office:body>
     <office:text>
          <office:forms form:automatic-focus=”false” form:apply-design-mode=”false”/>
          <text:sequence-decls>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Illustration”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Table”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Text”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Drawing”/>
               <text:sequence-decl text:display-outline-level=”0″ text:name=”Figure”/>
          </text:sequence-decls>
          <text:p text:style-name=”P1″>Sein oder Nichtsein, das ist hier die Frage</text:p>
     </office:text>
</office:body>

Die ersten Zeilen definieren den Hauptteil des Dokuments und die Tatsache, dass es sich um einen Text handelt. Die folgenden Zeilen sind Deklarationen, die in diesem Fall nichts hinzufügen, aber in anderen Kontexten Informationen über andere Elemente des Dokuments liefern würden.

Die entscheidende Zeile lautet: Sein oder Nichtsein, das ist hier die Frage, die einen Absatz definiert, seinen Stil (P1) angibt und den Inhalt liefert: Sein oder Nichtsein, das ist hier die Frage. Klar und für jeden Benutzer lesbar, der nun über die Schlüssel verfügt, um auf das Dokument zuzugreifen und dessen Inhalt zu verwalten, d. h. das Produkt seines Geistes.

Natürlich würden komplexere Dokumente und Inhalte einer komplexeren content.xml-Datei entsprechen, wobei jedoch stets die Lesbarkeit der Inhalte und die Einfachheit des XML-Schemas zu beachten sind.

OOXML: Was passiert innerhalb der Datei?

Sehen wir uns einmal an, was passiert, wenn dasselbe Dokument im DOCX-Format gespeichert, geschlossen und proprietär ist und künstlich komplex gestaltet wurde. Die Datei heißt document.xml und nicht content.xml, und dies wäre natürlich nicht weiter von Bedeutung, wenn es nicht ein weiteres Zeichen für die Komplexität des Formats wäre, da die Datei im Fall von Excel workbook.xml und im Fall von PowerPoint slide1.xml heißt und so weiter.

Die Datei document.xml eines Textdokuments, das nur den Satz „Sein oder Nichtsein, das ist hier die Frage“ enthält, ist 41 Zeilen lang: Die erste Zeile enthält Verweise auf alle verwendeten proprietären Elemente (wie wordprocessingCanvas, VML und WordML), und alle folgenden Zeilen beziehen sich auf den Inhalt:

<w:body>
     <w:p xmlns:wp14=”http://schemas.microsoft.com/office/word/2010/wordml” wp14:paraId=”2DC08235″ wp14:textId=”776AF5CB”>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”>Sein oder </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>Nicht</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> sein, </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>das</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>ist</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> die Frage</w:t>
          </w:r>
     </w:p>
     <w:sectPr>
          <w:pgSz w:w=”11906″ w:h=”16838″ w:orient=”portrait”/>
          <w:pgMar w:top=”1440″ w:right=”1440″ w:bottom=”1440″ w:left=”1440″ w:header=”720″ w:footer=”720″ w:gutter=”0″/>
          <w:cols w:space=”720″/>
          <w:docGrid w:linePitch=”360″/>
     </w:sectPr>
</w:body>

Unverständlich und unlesbar. Ich wage es, jeden Nutzer herauszufordern, einen Text beliebiger Komplexität aus einem XML-Dokument wie diesem zu rekonstruieren, wenn die Originaldatei beschädigt ist. Im Fall von ODF konnten wir sogar Dokumente mit Hunderten von Seiten oder Präsentationen mit Dutzenden von Folien rekonstruieren, da der Inhalt für jeden Nutzer lesbar war, auch für Nicht-Techniker.

Versuchen wir uns einmal vorzustellen, wie groß die Dateien content.xml und document.xml wären, wenn statt des Satzes von Prinz Hamlet alle 5.566 Zeilen der gesamten Tragödie in der Originalfassung von William Shakespeare enthalten wären. In diesem Fall spricht der Unterschied für sich: content.xml ist 5.598 Zeilen lang (32 Zeilen mehr als der Text), document.xml ist 93.289 Zeilen lang (87.723 Zeilen mehr als der Text).

Dateikomplexität als neue Lock-in-Strategie

Diese Komplexität der Dateien wird dem Benutzer bewusst verborgen, der auf seinem Bildschirm ein normal aussehendes Dokument sieht und keine Ahnung hat, dass er eine Datei auf seiner Festplatte oder in der Cloud schreibt, die Eigenschaften aufweist, die denen der proprietären Dateien aus dem letzten Jahrhundert sehr ähnlich sind, die ohne die Software, mit der sie geschrieben wurden, nicht lesbar sind.

Ein Benutzer, der glaubt, in Bezug auf die digitale Souveränität bedeutende Fortschritte erzielt zu haben, weil er ein Format verwendet, das er für offen und standardisiert hält, das aber im Gegenteil noch schlechter ist als die Binärformate der 1900er Jahre – die nichts anderes waren als das Schreiben dessen, was sich im Speicher befand –, da es auf XML basiert ein Algorithmus ist, der mit einem routinemäßigen Update aus der Ferne geändert werden kann (wie es in der Realität der Fall ist, wo dasselbe Dokument im DOCX-Format geschrieben wird, aber jedes Mal mit einer völlig anderen XML-Syntax, basierend auf Parametern, die nur dem Anbieter, d. h. Microsoft, bekannt sind).

Es handelt sich also um ein noch geschlosseneres und proprietäreres Format als die binären Formate, die es 2006 abgelöst hat. Letztere waren das Ergebnis der Übertragung des Speicherinhalts in Dateien, waren vorhersehbar und konnten emuliert werden, während OOXML aufgrund des Algorithmus unvorhersehbar ist und daher ohne ständige Untersuchung seiner zahlreichen Weiterentwicklungen kaum zu emulieren ist.

OOXML ist ein theoretisch offenes und standardisiertes Format, das in Wirklichkeit jedoch geschlossen und proprietär ist. Es stellt die neueste Entwicklung der Lock-in-Strategie dar, die allen Microsoft-Produkten für individuelle Produktivität zugrunde liegt und einen geschätzten Umsatz von über 25 Milliarden US-Dollar pro Jahr sowie einen geschätzten Nettogewinn von über 20 Milliarden US-Dollar pro Jahr sichert (alle Zahlen sind Schätzungen, da die Zahlen der Analysten nicht mehr verfügbar sind und wahrscheinlich unter den tatsächlichen Zahlen liegen).

Vielleicht ist es an der Zeit, dass supranationale Organisationen, zentrale und lokale Regierungen und wahrscheinlich auch einzelne Nutzer ihre Augen öffnen und einen einfachen Schritt in Richtung digitale Souveränität machen, d. h. die Verwaltung von Dokumenten und deren Inhalten unabhängig von den kommerziellen Entscheidungen eines einzelnen Unternehmens, indem sie ODF übernehmen und OOXML aufgeben.