Category: Open Document Format

A document format is a tool for sharing knowledge and, as such, should be as simple and accessible as possible in relation to the complexity of the document content itself. This remains true even when the format is based on an XML schema that is hidden from users when the document is displayed on screen.

Unfortunately, while an XML schema can be simple, it can also be unnecessarily complex, bloated, convoluted and difficult to implement without specific knowledge of its features. This is true even if the on-screen documents are identical. In this case, complexity is an intentional tactic used to lock users into a vendor, as is the case with the Microsoft 365 document format.

An XML schema comprises the structure, data types and rules of an XML document and is described in an XML Schema Definition (XSD) file. This tells the PC what to expect and checks that the data follows the rules. In theory, XML and XSD together form the basis of the concept of interoperability. However, in practice, an XML schema can be made so complex that it becomes a barrier rather than a bridge.

An “artificially complex” XML schema goes beyond the level of complexity needed to display even the most intricate content on screen. In fact, it is completely disconnected from the actual complexity of the content, to the extent that even a simple sentence such as “To be, or not to be, that is the question” becomes an inextricable sequence of tags that users cannot access.

This artificial complexity is characterised by a deeply nested tag structure with excessive abstraction, dozens or even hundreds of optional or overloaded elements, non-intuitive naming conventions, the widespread use of extension points and wildcards, the multiple import of namespaces and type hierarchies, and sparse or cryptic documentation.

In the case of the Microsoft 365 document format, the only characteristic not present is sparse or cryptic documentation, given that we are talking about a set of documents totalling over 8,000 pages. All the other characteristics are present to a greater or lesser extent, making life almost impossible for a developer trying to implement the schema.

To illustrate how this translates into a lock-in strategy, consider a railway system where the tracks are accessible to all, but the main train manufacturer imposes its own incredibly complicated control system. In theory, anyone could build a train compatible with the tracks, but the control system specifications are so convoluted that only the main train manufacturer can ultimately offer rail services.

The worst thing is that passengers don’t realise they are being held hostage by technical constraints that they cannot understand until ticket prices rise or the number of cities served declines. At this point, the main manufacturer can dictate its terms, which passengers are forced to accept.

This is very similar to what is happening in the world of information technology, where Microsoft is effectively forcing its customers to switch from Windows 10 to Windows 11 against their will. This switch has no technical justification and locks customers into using Windows 11 and Microsoft 365. This is because customers have completely ignored the problems that arise from using proprietary technologies.

If, over the years, the millions of Microsoft users who uncritically accepted a narrative that was credible to non-technical users but divorced from technological reality had taken a critical stance towards this monopoly, which would have raised doubts in any other sector, we would be in a very different situation today.

Instead, these users – including governments and supranational organisations – have allowed lock-in strategies, in which Microsoft 365’s artificially and unnecessarily complex XML document schema plays a fundamental strategic role, to become increasingly sophisticated and pervasive.

Therefore, if you are developing or choosing an XML-based system, bear in mind that complexity imprisons people, whereas simplicity and clarity set them free.

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.

Over the course of its 20-year history, the ODF standard has been adopted, or at least recommended, by numerous supranational bodies and several countries on almost every continent. However, this does not necessarily mean that the ODF standard is used in accordance with these decisions, which are often laws in their own right, as Microsoft’s substantial lobbying and misinformation campaigns aimed at protecting its revenue of around $25 billion generated by the proprietary OOXML format (DOCX, XLSX and PPTX) encourage the use of the latter. This is despite the fact that the disadvantages for national systems, communities of citizens and individuals are very easy to demonstrate: loss of control over content, interoperability problems and dependence on the commercial strategies of a single vendor.

The information in this post is based on my research into sources relating to the adoption or recommendations for the use of ODF. I began compiling this collection of documents around 2010 and continue to update it annually. Over the last twelve months, I have also used artificial intelligence in my research, which has helped me find some articles.

Unfortunately, formal adoption or recommendation of ODF does not guarantee its actual use in accordance with the law. For example, the latest version of Italy’s Digital Administration Code explicitly prohibits the use of OOXML because it is not a standard, yet this decision is largely ignored by public bodies.

SOVEREIGN BODIES

NATO requires all 28 member countries to use ODF as the standard format for document exchange.

UN and NGOs: UN organisations favour standard and open formats to ensure that all documents remain accessible and do not depend on expensive or restricted tools. This is why ODF is used for reports, policy drafts, and collaborative documentation between teams.

European Commission: has taken a strong stance in favour of open standards and promotes the use of formats such as ODF in documents through its open source software strategy. The European Parliament, the European Commission and the EUIPO (European Union Intellectual Property Office) have integrated LibreOffice and ODF into their internal workflows to ensure greater transparency and language neutrality.

EUROPE

Belgium: Since September 2007, all Belgian federal government departments have been required to accept and read ODF documents, and a memorandum has established ODF as the standard for the exchange of office documents within the federal public administration.

Denmark: From 1 April 2011, the Danish Parliament has mandated the use of ODF by state authorities for the exchange and archiving of documents, whereas previously agencies were only required to accept ODF documents. In recent weeks, articles have claimed that the Danish government will formally migrate to open-source software and, therefore, to ODF. We are, of course, seeking confirmation of this project.

Finland: The Ministry of Justice and other ministries have adopted ODF as the main document format.

France: The Référentiel Général d’Interopérabilité (RGI) recommends ODF as the preferred format for office documents in public administrations. Agencies are therefore encouraged to use ODF for creating and archiving text documents, spreadsheets, and presentations.

Germany: The German Council for Information Technology Planning, representing the federal and state governments, has committed to making ODF the standard for document management in public administration by 2027. The Ministry of Foreign Affairs and several federal courts already use ODF exclusively. Several federal states and municipalities have also switched to ODF-compatible office suites, such as LibreOffice and Collabora Online. ODF is cited as a core element of Schleswig-Holstein’s digital sovereignty strategy.

Italy: The Digital Administration Code only allows ODF in its guidelines for public administration, as OOXML does not meet the open standard criteria contained in the document’s glossary.

Netherlands: The Dutch government mandates the use of open standards, including ODF, for all data exchanges in the public sector, and adoption is monitored by an active political community that supports implementation.

Slovakia: All public authorities must be able to read and use ODF for electronic communication and publication of documents, including those with electronic signatures.

Spain (Andalusia and Extremadura): These regions require government agencies to use ODF (or PDF/A for static documents) for communication with each other and with citizens.

Switzerland: Government agencies are recommended to use ODF for document exchange with citizens or other agencies.

United Kingdom: In 2014, the British government adopted ODF as the sole standard for sharing and collaborating on editable documents across the public sector. The Home Office has a formal ODF adoption plan and does not reject ODF documents from citizens or businesses.

AMERICA

Argentina (Province of Misiones): The use of ODF is mandatory within government administrative organisations.

Brazil: Since 2010, proprietary formats have been prohibited in the federal public administration and ODF has been the standard for all office documents. It is mandatory in federal IT policies and is widely used in ministries and state governments. SERPRO (the federal data management service) ensures that national document workflows comply with the ODF standard.

Uruguay: public documents must use ODF for editable files and PDF for fillable forms and non-editable documents.

Venezuela: all federal government organisations must use ODF 1.0 for editable documents.

ASIA

India: India’s policy on the adoption of open standards for e-governance includes ODF as the preferred format for all federal and state services, particularly where vendor neutrality is critical for affordability and scalability.

Taiwan: The Ministry of Education has introduced ODF-compliant tools in all schools, and local governments use LibreOffice for daily administration.

AFRICA

South Africa: South Africa’s MIOS (Minimum Interoperability Standards) policy aims to ensure a future-proof digital government and access for all. It promotes open standards and lists ODF as an accepted format.

CASE STUDY

Monaco: In 2013, the city of Monaco made headlines when it migrated 15,000 desktops to Linux and OpenOffice/LibreOffice, adopting ODF. Despite positive results and significant cost savings, the project faced strong political opposition backed by the Microsoft lobby. In 2017, part of the migration was cancelled. This case is emblematic because it highlights the complexity of vendor lock-in and demonstrates the pressure that public institutions face from proprietary vendors to maintain a monopoly that is detrimental to the institutions themselves and their citizens.