TDF Community Blog

Unfortunately, I keep reading about open-source software advocates who happily use Microsoft’s proprietary DOCX, XLSX and PPTX formats for their documents and therefore prefer proprietary software such as OnlyOffice to LibreOffice. Others write outrageous things such as: “OOXML is a standard format, and we have to accept it.”

I would therefore like to take this opportunity to clarify, once and for all, why OOXML has never been, is not, and will never be a standard format unless Microsoft decides to completely redesign its office applications.

I consider this impossible in light of past decisions, such as Excel’s inability to handle elements of the human genome properly. This forced the scientific community to change the names of these elements due to Microsoft’s refusal to fix an obvious Excel bug.

In other words, because of Microsoft, all of us citizens of the world have been affected by the change of the names of some elements of our genome, with all that this entails for scientific research and, consequently, for the treatment of genetic diseases. This is an enormously important fact that has not received sufficient publicity in the media, but it illustrates how willing Microsoft is to overlook everything for its own commercial interests.

But let’s get back to OOXML.

In theory, OOXML (Office Open XML) is an ISO/IEC standard (ISO/IEC 29500), despite heavy technical criticism being raised by many parties during the process and completely ignored by ISO/IEC. This shows that it is not a standard, let alone an open standard.

The following is a summary of these criticisms:

Complexity of specifications: the standard is extremely voluminous (~7,000 pages), making it virtually impossible for third parties to implement correctly. This contrasts sharply with competing standards such as ODF, which are much more concise.

Implementation inconsistencies: Microsoft Office applications do not implement the standardized version (ISO/IEC 29500 Strict), but use the “Transitional” variant, which includes compatibility features with legacy formats that contradict the stated goal of being a clean, modern, and above all open and standard format.

Proprietary dependencies: The specifications refer to several undocumented legacy behaviors of previous versions of Microsoft Office and require implementers to decode Windows-specific features to achieve compatibility.

Binary blob remnants: Despite being based on XML, OOXML incorporates binary data structures in many places, particularly for backward compatibility with legacy formats, and this compromises the transparency that XML should guarantee.

Platform-specific elements: The standard contains Windows-specific elements related to fonts, rendering, and other system behaviors that make any cross-platform implementation difficult or even impossible.

Controversy over the standardization process: The fast-track approval process adopted for OOXML by ISO/IEC was highly controversial, with allegations of procedural irregularities and vote manipulation raising legitimate doubts about the validity of the standard.

These issues meant that, although OOXML technically became a standard, it has always been a proprietary Microsoft format specification and not a truly vendor-neutral open standard.

In the coming weeks, I will explore some of the claims made in this post in detail, with all the relevant technical elements.

For now, anyone interested can take a look at this PDF presentation from 2018, referring to ISO/IEC 29500-1:2016 (and the corresponding ECMA 376), which lists some of the issues and provides technical details that clarify at least some of the claims.

Please be aware that some of the slides referring to ECMA 376 are related to an old version of the standard and as such may be obsolete. The presentation will be updated with references to the current version of ECMA 376.