Month: June 2025

To write this article, I went beyond the limits of my technical knowledge, which is that of an advanced user who has studied standard formats and their characteristics in depth, to understand why standard formats – one of the pillars of digital sovereignty – and proprietary formats – their opposite, and one of the biggest obstacles to digital sovereignty – are not perceived as a problem by most PC users, who continue to use Microsoft’s proprietary formats and place the access and availability of their content in the hands of the US company.

To try to remedy this problem, I will try to explain as simply as possible, using non-technical language (which may shock developers, but this article is not aimed at them), some technical features of the Open Document Format (ODF), which make it the cornerstone of an open and vendor-independent ecosystem for office documents, defending the digital freedoms of all users and the governance of their content.

I will begin by explaining how to unpack an ODF file, which is nothing more than a set of XML files and other files (for images and videos) contained within a ZIP folder, in order to examine its internal components and, in particular, the content.xml file, which is the one that contains the body of the document (i.e., the user’s intellectual property).

The aim is not so much to assess conformity (compliance with specifications) and interoperability (the ability to exchange files consistently between tools), as these aspects will always be dealt with by specialists, but rather to understand the advantages for the user of the open and standard format over the closed and proprietary format (which is falsely standard, since it was approved by ISO/IEC in defiance of “their” definitions of standards).

For this reason, I will make a brief concluding digression on the characteristics of the OOXML (Office Open XML) format used by Microsoft Office and Microsoft 365, again to clarify to users the risks they face and the harm they do to themselves and other users when they use DOCX, XLSX and PPTX formats, as well as the ‘gift’ they are giving to Microsoft, to whom they are effectively entrusting the management and future of their content.

Analysing an ODF file

Take any document you have created with LibreOffice. For convenience, I recommend starting with a text document created with LibreOffice Writer, with the ODT extension. Before doing anything else, duplicate the file, because an error in the procedure could make it unreadable, and move the original to another folder.

Rename the copy, replacing the ODT extension with the ZIP extension, without deleting the dot. The file icon will become that of a compressed file. If it becomes white or empty, you have done something wrong or deleted the dot. Check all the steps until the icon becomes that of a compressed file.

At this point, right-click on the icon and select “unzip” or “expand” to extract the contents of the compressed file into a folder with the same name as the file without the extension.

The folder will contain the following items:

• the META-INF folder, which will contain the manifest.xml file
• the Thumbnails folder, which may contain the thumbnail.png file
• the content.xml file, which contains the body of the document
• the styles.xml file, which contains the style definitions
• the meta.xml file, which contains the file metadata (author, creation date, last modification date, etc.)
• the settings.xml file, which contains the application settings

Each XML file within an ODF document must comply with the RelaxNG XML schema, or REgular LAnguage for XML Next Generation, created by OASIS in 2001 and 2002, which is simpler – and therefore more accessible to non-technical users – than other XML schemas. The packaging rules are defined by the OpenDocument Packaging specifications.

In addition to schema validation, it must meet a number of conditions.

• Structural compliance: the elements of the ZIP and manifest.xml files
• Functionality compliance: all standard and optional functionality (metadata, styles, tables, graphics, etc.)
• Formula compliance: spreadsheet formulas must be compatible with OpenFormula semantics
• Security compliance: ODF profiles, encryption, digital signature

The manifest.xml file contained in the META-INF folder must list all the files in the ZIP file, with their media type:

<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>

Simply omitting a file or making an error in the description of its media type is enough to make the ODF file structurally non-compliant.

ODF: the importance of the content.xml file

To understand the user benefits of an open standard format such as ODF over a proprietary format, even one that is theoretically open such as OOXML, a quick analysis of the content.xml file of ODF files and its equivalent in OOXML files, which differs depending on the file type (and this alone is a sign that the development of OOXML did not take user needs into account at all, but focused on artificially increasing complexity), is sufficient.

Let’s take a first example, based on one of the most famous phrases in the history of world literature, namely “to be, or not to be, that is the question” uttered by the protagonist of William Shakespeare’s Hamlet.

The content.xml file of a text document containing only this sentence is 32 lines long: the first 18 provide references to all the standards used (such as X-Forms and MathML), list the fonts used in the document styles, and define the styles (in this case only one, given the length of the text and the absence of formatting).

The next 13 lines are as follows:

<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″>To be, or not to be, that is the question</text:p>
     </office:text>
</office:body>

The first lines define the body of the document and the fact that it is a text. The following lines are declarations that, in this case, do not add anything, but in other contexts would provide information about other elements of the document.

The key line is this: <text:p text:style-name=‘P1’>To be, or not to be, that is the question</text:p>, which defines a paragraph, declares its style (P1) and provides the content: To be, or not to be, that is the question. Clear and readable by any user, who now has the keys to access the document and manage its contents, i.e. the product of their brain.

Of course, more complex documents and contents would correspond to a more complex content.xml file, but always respecting the readability of the contents and the simplicity of the XML schema.

OOXML: what happens inside the file

Let’s see what happens in the case of the same document saved in DOCX format, closed and proprietary, and artificially complex. The file is called document.xml and not content.xml, and this – obviously – would not be significant if it were not a further sign of the complexity of the format, given that in the case of Excel the file is called workbook.xml and in the case of PowerPoint it is called slide1.xml, and so on.

The document.xml file of a text document containing only the phrase “To be, or not to be, that is the question” is 41 lines long: the first provides references to all the proprietary elements used (such as wordprocessingCanvas, VML and WordML), and all the subsequent lines relate to the content:

<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”>To be, or </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>not</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> to be, </w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t>that</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>is</w:t>
          </w:r>
          <w:r w:rsidR=”6B254FF6″>
               <w:rPr/>
               <w:t xml:space=”preserve”> the question</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>

Obscure and unreadable. I challenge any user to reconstruct a text of any complexity from an XML document like this, if the original file is damaged. In the case of ODF, we were able to reconstruct even documents of hundreds of pages, or presentations of dozens of slides, because the content was readable by any user, even non-technical ones.

Let’s try to imagine the size of the content.xml file and the document.xml file if, instead of Prince Hamlet’s sentence, there were all 5,566 lines of the entire tragedy, in the original version written by William Shakespeare. In this case, the difference speaks for itself: content.xml is 5,598 lines long (32 lines more than the text), document.xml is 93,289 lines long (87,723 lines more than the text).

File complexity as the new lock-in strategy

This file complexity is intentionally hidden from the user, who sees a normal-looking document on the screen and has no idea that they are writing a file on their hard drive or in the cloud that has characteristics very similar to those of the proprietary files used in the last century, which are unreadable without the software with which they were written.

A user who believes they have made significant progress in terms of digital sovereignty because they use a format they believe to be open and standard but which, on the contrary, is even worse than the binary formats of the 1900s – which were nothing more than the writing of what was in memory – because, being based on XML, it is the offspring of an algorithm that can be modified remotely with a routine update (as happens in reality, where the same document is written in DOCX format but with a completely different XML syntax each time, based on parameters known only to the vendor, i.e. Microsoft).

So, it is an even more closed and proprietary format than the binary formats it replaced in 2006. The latter, being the result of writing what was in memory to files, were predictable and could be emulated, while OOXML is unpredictable due to the algorithm, and therefore almost impossible to emulate without constant study of its many evolutions.

OOXML is a theoretically open and standard format, which in reality is closed and proprietary, and represents the latest evolution of the lock-in strategy that underpins all Microsoft products for individual productivity, defending an estimated turnover of over $25 billion per year, with an estimated net profit of over $20 billion per year (all figures are estimates, as analysts’ figures are no longer available and are probably lower than the actual figures).

Perhaps the time has come for supranational organisations, central and local governments, and probably also individual users, to open their eyes and take a simple step forward towards digital sovereignty, i.e. the governance of documents and their content independent of the commercial choices of a single company, by adopting ODF and abandoning OOXML.

The Open Document Format (ODF) is an open standard format for office documents, which offers a vendor-independent, royalty-free way to encode text documents, spreadsheets, presentations, and more.
However, to realise its potential, it is necessary to understand the concepts of compliance – the degree to which an implementation adheres to ODF specifications – and interoperability – the ability to exchange and view ODF files without loss of fidelity or functionality across different applications and platforms.

ODF is an XML-based file format that has been standardised by OASIS and ratified by ISO/IEC 26300. Milestones include:

• ODF 1.0 (2006): the initial version defining the basic document types: text (.odt), spreadsheet (.ods) and presentation (.odp).
• ODF 1.1 (2012): updates to formula specifications and accessibility improvements were made, but it was never submitted for standardisation.
• ODF 1.2 (2015): introduces digital signatures, RDF metadata, and OpenFormula for standardising spreadsheet calculations.
• ODF 1.3 (2020): an extension of security features, including improvements to encryption and import/export conventions, as well as a clarification of compliance clauses.

Each version has strengthened the role of ODF as a universal interchange format, ensuring that documents remain readable and editable in all programs, both now and in the future.

Definition of compliance

Compliance refers to the extent to which a given software implements the ODF standard. It comprises several levels:

1. Structural compliance: ensures that file archives contain the expected XML files (e.g. content.xml, styles.xml and meta.xml), in accordance with the ODF Packaging specifications.
2. Schema validation: verifies that the XML content matches the applicable ODF schemas (Relax NG or W3C XML Schema). This prevents a <draw:image> element, for example, from appearing where only text is permitted.
3. FeatuSecurity profilesre compliance: supports the required features (styles, tables, charts and metadata) and the correct implementation of the optional features required by the application (digital signatures, encryption and change tracking).
4. Formula compliance: for spreadsheets, adherence to OpenFormula specification ensures that formulas behave consistently across different applications.
5. Compliance statements and profiles: applications often declare their compliance levels (e.g. ODF 1.2 Part 1: OpenDocument Schema). Some define profiles, which are subsets of the full standard tailored to specific industries or workflows.

Non-compliant files risk becoming unreadable or displaying incorrectly in other applications. Validating ODF schemas and integrating compliance tools enables developers and users to guarantee the longevity and accuracy of documents.

The interoperability landscape

Even when two applications claim ODF compliance, disparities can arise.

• Rendering differences: variations in character substitution, line spacing or image placement can slightly alter the layout.
• Functionality differences: for example, an editor may support digital signatures, but implement them in a way that causes signatures to be rejected when files are exchanged.
• Use of extensions: some applications use proprietary extensions (e.g. custom XML blocks) that others do not recognise, which can result in data or content loss.
• Metadata management: different handling of document properties, such as author, version history or custom metadata, can hinder workflows.

To achieve strong interoperability, systematic testing is required.

1. Automated schema validation: tools such as ODF Validator can check thousands of files against ODF schemas in batches.
2. Feature compliance suites: OASIS provides test suites that cover every aspect of the ODF specification, including basic document elements and encryption profiles.
3. Round-trip testing: save a document in application A, open it in application B and save it again, then reopen it in application A to detect any differences.
4. Visual regression testing: use headless rendering engines (e.g. LibreOffice in server mode) to generate PDFs or bitmaps for pixel-level comparison.
5. Community reports: projects such as ODF Plugfest bring vendors together to exchange test files and submit interoperability reports.

Best practices for ensuring compliance and interoperability:

1. Adherence to the core standard: avoid proprietary extensions unless they form part of an agreed ODF profile.
2. Early and frequent validation: integrate schema and conformance testing into CI/CD pipelines for document-centric applications.
3. Prioritise OpenFormula: when creating a spreadsheet, use standard functions and avoid vendor-specific formula syntax.
4. Adopt the Flat ODF format: the Flat ODF format (.fodt, .fods and .fodp) stores the entire document in a single XML file, making it easier to compare, validate and process in scripts.
5. Document compliance statements: indicate the ODF version supported by the application, as well as the schema, encryption and signature parts.
6. Participate in plugfests and community testing: real-world feedback is valuable, so it is important to participate in interoperability events and contribute to public issue trackers.
7. Make smart use of metadata: use ODF metadata elements (e.g. dc:meta, RDF blocks) to ensure the consistency of document properties when transferring between tools.

Looking ahead: ODF 1.4 and beyond

Although ODF 1.3 has addressed many functional issues, the ecosystem continues to evolve.

• Accessibility improvements: better support for tagged PDFs, ARIA roles and semantic markup.
• Native cloud editing: harmonisation of ODF with collaborative protocols (e.g. WOPI and CMIS) to enable real-time co-authoring.
• Extended multimedia management: richer multimedia support is incorporated (e.g. video and embedded web components), while maintaining interoperability.
• Security profiles: standardisation of profiles for high-security environments (e.g. government or healthcare), combining encryption, signatures and content redaction.

Conclusion

ODF compliance and interoperability are fundamental to document longevity, workflow resilience, and user trust. By adhering to ODF schemas, testing across multiple applications and adopting community best practices, organisations can safeguard their content against vendor lock-in and format degradation. As it continues to mature, ODF is set to remain the foundation of open, accessible and durable office documents.