When different systems, applications or organisations need to communicate with each other and actually understand what is being said, interoperability is key. It enables a hospital’s software to communicate with an insurance company, for example, or one vendor’s inventory system to synchronise with another’s logistics platform.

At the heart of many of these data exchanges is XML.

XML (Extensible Markup Language) may not be new or flashy, but it remains one of the most powerful tools for achieving reliable, structured interoperability across diverse platforms.

Why is interoperability so hard?

Systems are built using different programming languages, data models and communication protocols. Without a shared format or structure, exchanging data can result in a complex web of custom APIs, ad hoc conversions, and manual adjustments.

To get systems working together seamlessly, you need:

• A standardised structure for data.
• A way to validate that structure.
• A format that is language-agnostic and platform-neutral.

XML ticks all these boxes.

How XML enables interoperability

1. Self-describing structure

XML uses tags to clearly label data:

<customer>
   <name>Maria Ortega</name>
   <id>87234</id>
</customer>

This means that a receiving system doesn’t have to guess what each field means, as it is explicitly defined. This reduces the risk of misinterpretation and supports automated parsing.

2. Schema validation

Using XSD (XML Schema Definition) or DTD (Document Type Definition), you can define the rules that an XML document must adhere to, such as which elements are required, which data types are valid and what the structure must be.

This is critical for:

• verifying incoming data
• preventing malformed or incomplete exchanges
• ensuring consistency across multiple systems

3. Namespaces for avoiding collisions

XML namespaces prevent tag name conflicts when data from different sources is combined.

<doc xmlns:h=”http://www.w3.org/TR/html4/” xmlns:f=”http://www.w3schools.com/furniture”>
   <h:table>…</h:table>
   <f:table>…</f:table>
</doc>

Without namespaces, systems could misinterpret elements with the same name but different meanings.

4. Cross-platform compatibility

XML is plain text. Any system that can read a file can read it, whether it’s written in Java, .NET, Python or COBOL. This makes it ideal for long-term data exchange and integration between legacy and modern systems.

XML in real-world interoperability

Healthcare: HL7 CDA/FHIR

Hospitals, clinics, insurance providers and pharmacies rely on XML-based formats to exchange clinical records, billing data and prescriptions. HL7’s CDA (Clinical Document Architecture) is a strict XML schema that is used worldwide.

In government, XML is used for e-government forms and tax data.

Tax filings, business registrations and compliance documents are often submitted in XML format. This ensures consistent structure across various jurisdictions and software vendors.

Publishing: DITA and JATS

XML standards are used for modular content creation and journal publishing to allow interoperability between authors, editors, publishers, and archive systems, even if they are using different tools.

Finance: XBRL

XBRL (eXtensible Business Reporting Language) uses XML to standardise financial reports, enabling regulators, investors and analysts to automatically process and compare data from …

Following the example of the German state of Schleswig-Holstein, which is moving 30,000 PCs from Microsoft Office/365 to LibreOffice, the Danish Ministry of Digitalisation is doing the same.

Caroline Stage Olsen, the country’s Digitalisation Minister, plans to move half of the employees to LibreOffice over the summer, and if all goes as expected, the entire Ministry will be free from Microsoft Office/365 later in the year.

In a LinkedIn post, Olsen summarised the reasons for switching to LibreOffice:

We must never make ourselves so dependent on so few that we can no longer act freely. Because far too much public digital infrastructure is today tied up with very few foreign suppliers. This makes us vulnerable. Also financially.

That is why we are now testing in parallel at the Ministry of Digitization how it works in practice when we work with open source solutions. Several municipalities are doing the same.

Not because we think it’s easy – but because we know it’s necessary to lead the way if we want to create more competition and innovation – and reduce our dependence on the few.

We in the LibreOffice project welcome this move, and look forward to seeing more governments and organisations getting control of their digital sovereignty and using public money for public code.

In my last article, I mentioned XML several times, perhaps assuming that all users had a basic understanding of it. Rereading it, I realised that an introduction to XML was needed for non-technical users, those who use XML every day without realising it, when they open a document, check the weather, place or receive an order online, or issue a digital invoice. XML works silently behind the scenes.

But what exactly is XML and why should it matter to non-techies? I will try to explain it in simple terms.

XML stands for eXtensible Markup Language, a way of organising information in a format that is easy for both people and computers to understand, helping different applications communicate and exchange data using a common language. Put simply, XML is a digital container that clearly labels information.

For example, this is a shopping list in XML format:


<groceryList>
  <item>
    <name>Bread</name>
    <quantity>1 loaf</quantity>
  </item>
  <item>
    <name>Milk</name>
    <quantity>2 litres</quantity>
  </item>
</groceryList>


Labelling helps computers and software understand exactly what each piece of information means.

In a hyperconnected world like ours, where apps and systems share data, XML allows that data to move between very different systems, such as credit card management apps and online shops. Without a common language like XML, communication between these systems would be much more complicated and slower, or even impossible.

So, XML is integrated into most everyday activities, even though it is completely hidden from users:

• All documents created by all office suites use XML, in some cases to facilitate transparency and interoperability, and in other cases to create a hidden layer of complexity with the aim of preventing transparency and interoperability.
• All apps that provide weather forecasts obtain updates by reading XML data issued by weather agencies.
• Almost all e-commerce applications use XML to manage communication between the website, the payment system, the bank and the shipping service.
• All blogs and news sites use XML to automatically transmit new content to readers.

XML is clear and easy to read because it organises data in an orderly manner with labels that are understandable to both humans and computers; it is flexible, as it is not limited to a single type of information and can be customised for different scenarios, from cooking recipes to flight schedules; and it is compatible with all platforms.

To appreciate the value of XML, you don’t need to have a deep understanding of the language, just know that it exists and that – when used properly, as in the case of the ODF format – it has the potential to help users achieve and protect their digital sovereignty.

Of course, it is equally important to know that XML can be used in exactly the opposite way, as is the case with Microsoft 365’s OOXML format (and previously Office), to limit users’ digital sovereignty and perpetuate lock-in through artificial file complexity.

In summary, XML is a silent enabler that ensures that users’ apps, services and data all speak …

Here’s our summary of updates, events and activities in the LibreOffice project in the last four weeks – click the links to learn more…

• We started the month with Episode 3 of the LibreOffice Podcast – this time looking at Quality Assurance (QA) in Free and Open Source Software. Watch it below – or on PeerTube.

• Then we announced the winners in the Month of LibreOffice, May 2025, providing information on how to get sticker packs. We’ve been sending out stickers and merchandise in the last few weeks, with a bit more to come!

• On June 6, we announced LibreOffice 25.2.4, the fourth minor update to our latest stable branch. All users are recommended to upgrade.

• Next, we posted another section from The Document Foundation’s Annual Report, “LibreOffice for End User Privacy”.

• The end of Windows 10 is approaching, so it’s time to consider Linux and LibreOffice! That’s the message behind the “End of 10” campaign, which we’re supporting.

• In the middle of the month, we posted news about a new tutorial added to the wiki, showing how to create colour wheels with LibreOffice.

• Throughout June, we posted various articles about ODF, the Open Document Format used by LibreOffice (and supported in many other office suites): An Analysis of the adoption of the Open Document Format; Understanding ODF compliance and interoperability; and A technical dive into ODF.

• Then we reported back from an event: LibreOffice at the Linux Arena in Pordenone, Italy.

• Before LibreOffice there was OpenOffice, and before OpenOffice there was StarOffice. And how was StarOffice developed? We talked to Stefan Soyka, who worked on the suite in the early ’90s, and has some entertaining stories to tell

• New LibreOffice merchandise is here! We updated our Spreadshirt shop with new designs and many extra items. Buy something and support LibreOffice – some of the proceeds go back to the project!

• Registration is now open for the LibreOffice Conference 2025. Join us from 4 – 6 September in Budapest – we’ll have technical talks, workshops, social events and more…

• And finally, we announced the new LibreOffice 25.2 user guides – awesome work from the documentation team.

Keep in touch – follow us on Mastodon, X (formerly Twitter), Bluesky, Reddit and Facebook. Like what we do? Support our community with a donation – or join our community and help to make LibreOffice even better!

The LibreOffice community has great news: the Writer, Calc, Impress, Draw, and Math User Guides are now available for version 25.2!

Yes, you read that right! With every new LibreOffice release, our Documentation Team works hard to keep up — and this time, we’ve shortened the gap between the software launch and the guides’ publication even more.

These user guides are the ultimate reference for anyone using LibreOffice — whether at home, at work, or at school. From spreadsheets to presentations, from text documents to complex equations: it’s all covered, clearly and accessibly.

The work is 100% community-driven! Jean Weber led the Writer guide, Peter Schofield coordinated the Impress, Draw, and Math guides, and Olivier Hallot headed the Calc guide.

Big thanks also to Dione Maddern, Celia Palacios, Ed Olson, B. Antonio F., Mike Kaganski, and Vasudev Narayanan for their valuable contributions.

Each new edition is more than just an update — it’s a chance to improve clarity, add the latest features, and deliver the best experience possible for end users. These guides complement the built-in LibreOffice Help and are perfect for deepening your knowledge.

The guides are available now for free download in PDF, ODT (OpenDocument format), and HTML (for online reading). And soon, you’ll be able to order printed copies via LuLu Inc.

Get your guides now:

• documentation.libreoffice.org
• books.libreoffice.org

Artwork: Eliane Domingos

Registration is now open for the LibreOffice Conference 2025! Join us from 4 – 6 September in Budapest We’ll have technical talks, workshops, social events and more…

Click here to learn more, and register

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 …

Get cool LibreOffice merchandise – and support our projects and community! We’ve updated our Spreadshirt shop with new designs, and part of the sales go to The Document Foundation, the non-profit organisation behind the suite.

Click here to visit the shop

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 …

LibreOffice is the successor project to OpenOffice(.org), which in turn was based on StarOffice, a proprietary office suite developed in the 1990s. Learn more about the history here! And let’s hear from Stefan Soyka, who worked on StarOffice from 1990 – 1992…

When did you join Star Division, and what did you work on?

I came from Berlin to Hamburg to work for Marco Börries in his Star Lab in spring 1990, together with my friend and study mate Stefan. Both of us joined the project more or less at the same time and shared the same first name, which caused some confusion at first.

The situation in Hamburg needs some explaining if you are new to it. The Writer application that is the foundation of what we use today is not the first Star Writer – but thesedays it is often referred to as Star Writer 6 or Star Writer Graphic. Marco’s company Star Division, based in rural Lüneburg not far from Hamburg, had developed and sold with considerable success a text processing application with the same name, that was an MS-DOS application based on a home-grown graphics framework. A team of freelance programmers was working on it under the lead of Sven-Ola Tücke.

This was also the tool we used to write the first drafts for specifications, by the way.

The old Star Writer had a solid fanbase and sold quite well even after Star Lab started in Hamburg. So it is fair to say that the money we burned in Hamburg was earned in Lüneburg.

Marco, however, had the right feeling that graphical user interfaces were already around and taking up speed. The future (that is the time we live in now) would belong to applications running on the main graphical user interface platforms at this time, being Microsoft Windows, the X Window System and macOS. Of course there were voices that argued that graphical user interfaces were only hampering productivity and real pros would always use the command line. That may sound a bit funny today, but I took it all in my heart.

When I arrived there, development had pretty much advanced in the compatibility layer named Star View, that allowed portable programming of both operating system functions and graphical user interfaces. There was, however, no application yet. Because I had worked on a C++/X Window System project on the ODA standard (ISO 8613, Open Document Architecture), I had some background on this and formed with some others the core of the Star Writer project team.

Tell us about the office location and team back then!

The offices of Star Lab at that time were at Heidenkampsweg, near Berliner Tor, in Hamburg in a quite modern building. I remember the adjacent gas station; many of us were heavy cigarette-smokers at that time, and I sometimes went there at night to get the next pack.

Dirk Bartels supervised the daily operations. He had a software company back in Berlin and …