When a file format moves faster than its standard

When a file format moves faster than its standard

Microsoft keeps a public document that explains how Office reads and writes the Office Open XML formats compared with the international standard behind them, ISO/IEC 29500. We counted its revision history on 26 October 2026. Since December 2009 Microsoft has published that document 57 times, 28 of them marked as major revisions, the latest on 18 August 2026. Over the same years Ecma-376, the specification ISO adopted as that standard, has reached its fifth edition, and the newest text of its core part is dated December 2016.

The two numbers describe the same thing from two ends. The files that offices exchange every day keep changing, the standard that those files cite changes far less often, and the gap between them is written down, revision by revision, by the vendor itself.

It is tempting to read that gap as a failure. We think it is better read as a description of how software actually progresses, and of what good practice looks like when a product moves ahead of the paper that defines it. This piece sets out what we counted, why we think progress should not wait for a committee calendar, and what an organisation choosing an office suite can do about the gap without taking sides in any argument about who is to blame for it.

What we counted, and where

We used three kinds of source, all read on 26 October 2026.

The first is the revision table of Microsoft's "MS-OI29500: Office Implementation Information for ISO/IEC 29500 Standards Support". Microsoft describes the document as covering "areas where the product is known to vary from or extend the specification", and it is written against ISO/IEC 29500:2012. The table lists every published version with a date, a protocol revision number and a revision class (Major, Minor or None). There are 57 rows from 15 December 2009 to 18 August 2026: 28 major, 10 minor and 19 with no change class. Major revisions have come in most years, with two in 2026 so far, in May and August.

The second is the Ecma International page for Ecma-376, the specification that ISO adopted as ISO/IEC 29500. It lists the current editions of its four parts: Part 1, Fundamentals and Markup Language Reference, 5th edition, December 2016; Part 2, Open Packaging Conventions, 5th edition, December 2021; Part 3, Markup Compatibility and Extensibility, 5th edition, December 2015; and Part 4, Transitional Migration Features, 5th edition, December 2016. Earlier editions date from December 2006, December 2008, June 2011 and December 2012.

The third is our own catalogue. We read every live product listing in five categories where file formats matter most to a buyer: productivity software (12 listings), spreadsheet software (20), presentation software (13), document management software (5) and PDF software (15). That is 65 listings. Twelve of them name a Microsoft Office format, such as DOCX, XLSX or PPTX, or say they open Office files. Three name the OpenDocument Format, among them LibreOffice and Zoho Show. Two name both. The other 52, four in every five, say nothing at all about which document formats they read or write.

That last figure is the one we find most useful, because it is about information rather than blame. Whatever a buyer thinks of either format, most product descriptions in these categories give them nothing to compare.

Two clocks that were never going to agree

Software and standards run on different clocks, and they always have.

An office suite ships on a product schedule. This year LibreOffice's major releases are numbered 26.2 and 26.8, two a year, with maintenance updates between them; The Document Foundation announced 26.8.1 on its blog on 2 October and confirmed its availability on 8 October. Each release of any office suite can add a feature that has to be saved somewhere in the file.

A formal standard runs on a review schedule. Drafts are prepared by a committee, circulated, commented on, balloted, revised and published. Each step exists for a good reason: it gives competitors, governments and independent implementers a fair chance to read the text and object before it binds anyone. But the result is that a standard describes the state of the art at the moment the ballot closed.

The open format is not exempt from this. OASIS approved OpenDocument 1.2 on 30 September 2011, lists version 1.3 as approved on 30 October 2020, and approved version 1.4 on 6 October 2025. That is three versions in fourteen years, from a process that The Document Foundation rightly describes as public and open to anyone. Policy then runs behind the standard in turn: the UK government's guidance on sharing and collaborating with government documents, last updated on 29 January 2026, still tells departments to use ODF 1.2, a version that has had two successors since.

None of this is a scandal. It is what happens when one process is optimised for shipping and the other for agreement. The useful question is not why the clocks disagree but what each party owes the user while they do.

A standard is a floor, not a ceiling

Reading the gap as "Microsoft has left the ISO standard behind" assumes the standard was meant to be a ceiling: a complete description of everything a conforming product may ever do. Most standards are not written that way, and this one was not.

The clearest evidence is in the standard itself. One of its four parts is titled Markup Compatibility and Extensibility. Its existence says that the authors expected producers to add markup that other readers would not understand, and set out a common way of doing it. A format with a dedicated extensibility part is a format designed to be extended.

The Document Foundation, which maintains LibreOffice and backs the OpenDocument Format, makes the same point plainly. Writing on 17 September 2026 about chart types that Microsoft added to Office from 2016 onwards, stored in a namespace known as chartex and documented outside the ISO/IEC 29500 text, it called this "entirely legal and perfectly normal commercial behaviour: a vendor improves its product and the file format evolves accordingly." Its complaint is about the consequence for other implementers, who are always behind, not about the act of improving the product.

Seen that way, the standard is the floor: the part of the format that every implementer can rely on because it went through the full process. The living format is that floor plus extensions. Box-and-whisker, Pareto, funnel and waterfall charts are useful to people who analyse data, and they reached users years before any committee could have balloted them. If those charts had had to wait for the next edition of Part 1, users would still be waiting, because there has been no new edition of Part 1 since December 2016.

Why progress should not wait for the next ballot

There is a version of this argument that says nothing should ship until it is standardised. We do not think it survives contact with how useful features are actually found.

Most good features are discovered by building them. A chart type, a collaboration mechanism or an accessibility improvement usually starts in one product, is refined by its users, and only then is understood well enough to write down. Standards that try to define features before anyone has built them tend to produce text that nobody implements. Standards that codify what has already been proven tend to stick. In that sense a product moving ahead of its standard is often the first half of the standards process, not a departure from it.

The web is the clearest example of a standards community that accepted this and changed its method. The HTML specification is maintained by the WHATWG as a "Living Standard"; the version we read on 26 October 2026 was last updated the same day. The WHATWG explains that roughly every six months the living text is snapshotted as a Review Draft so that participants can make their patent commitments against a fixed version. That is a working answer to the two-clock problem: a document that changes as often as the products do, with periodic fixed points for the people who need something stable to cite.

Holding progress back for a ballot would also not help the organisations that most need stability. A government archive or a law firm does not benefit from an office suite that refuses to add a feature; it benefits from knowing exactly which features its files depend on and whether those features are documented well enough to be read in twenty years. Those are questions about documentation and preservation, and both can be answered without slowing anyone down.

What good practice looks like when the product moves first

If extension is normal, the measure of a vendor or a project is how it behaves when it extends. We see three duties, and the examples below show that each of them is already being met somewhere.

Document the difference, in public, as it happens

Microsoft's implementation notes are the example here. A document that has been revised 57 times in seventeen years, with a dated history anyone can download, is a commitment of real effort. It lets an independent developer find out how Office treats a particular element without reverse engineering it, and it makes the size of the gap measurable, which is how we were able to count it. The improvement we would ask for is the obvious one: a cross-reference between each extension and the standard text it extends, so that implementers can see at a glance what the floor is and what sits on top of it.

Preserve what you cannot yet read

The Document Foundation's 17 September post describes three ways an office suite can treat a chart it does not understand: refuse the file, silently drop the chart, or keep the chart's definition intact, tell the user it cannot be shown, and write it back unchanged when the file is saved. LibreOffice 26.8 takes the third route for the chartex chart types, with one stated exception: charts with regional maps lose most of their geographic content. The post's point is that silent loss is the worst outcome, because the damage only appears when someone else opens the document.

Round-trip preservation is the duty that makes extension safe for everyone else. A format can move ahead of its standard without breaking anything, as long as every other reader carries the new parts through untouched.

Refresh the standard on a cadence people can plan around

OASIS's three ODF versions, and Ecma's 2021 edition of the packaging part, show that formal standards do move. The gap is widest where a part has not been revised for a decade while the products using it have been revised every year. A predictable review cadence, of the kind the WHATWG runs with its six-monthly snapshots, would let vendors, governments and independent implementers plan around the next fixed point instead of waiting for an unannounced one. Procurement rules that name a format would then stay current too, rather than pointing, as the UK guidance does today, at a version that has been superseded twice.

What a buyer can do now

An organisation choosing or reviewing an office suite does not have to settle any argument about formats. It can make the gap visible and manageable with a few concrete steps.

• A requirement for "ODF" or "OOXML" leaves the version open, so name it: ODF 1.4 if that is what you need, or ISO/IEC 29500 with the conformance class you expect, and ask suppliers which version their product writes by default.
• Ask every candidate suite what it does with content it cannot display: whether it refuses, drops or preserves it on save. Ask for the answer in writing for the specific features your organisation uses, such as newer chart types, tracked changes, form fields and macros.
• Take a sample of real documents from your own archive, open and save them in each candidate, then open the results in the original application. The differences you find are the ones that will matter, and no listing can tell you them.
• An archive is easier to keep readable if you know which parts of it depend on extensions that are documented only by one vendor.
• Product listings will not answer this for you yet. In the five categories we read, 52 of 65 listings say nothing about formats, so the question has to go to the vendor directly, and vendors who state the versions they read and write make that step shorter.

Where this leaves the standard

It would be easy to conclude that a standard which has not changed its core text in ten years no longer matters. We think the opposite. The 2016 text of Part 1 is a large part of the reason that many different products can open the same spreadsheet at all; the extensions sit on top of something that works. The ODF 1.4 specification is the reason any developer can build a conforming editor from published documents.

What has changed is the job a standard can be asked to do. It can no longer be a complete description of a living product, and it was probably never going to be. It can be a dependable floor, refreshed on a cadence, with the vendors who build above it documenting what they add and the implementers who read their files preserving what they cannot yet show. All three parts of that are already happening somewhere. The progress worth asking for is that they happen everywhere, and on a timetable a buyer can plan around.

Related on TrustList:

• Rutba Office: a free desktop office suite that opens Outlook archives and leaves your files alone
• Dutch tax office drops Microsoft 365 for on-premises and open source
• CMA proposes special status for Microsoft in UK business software

Sources

• Microsoft Learn: MS-OI29500 Office Implementation Information for ISO/IEC 29500 Standards Support, revision history (read 26 October 2026) - 18 August 2026
• Ecma International: ECMA-376, Office Open XML file formats, editions of parts 1 to 4 (read 26 October 2026) - December 2021
• OASIS: Open Document Format for Office Applications (OpenDocument) Version 1.4 - 6 October 2025
• OASIS: OpenDocument Version 1.3 - 30 October 2020
• OASIS: OpenDocument Version 1.2 - 30 September 2011
• GOV.UK: Sharing or collaborating with government documents (open standards for government) - 29 January 2026
• The Document Foundation: LibreOffice 26.8 and interoperability, preserving what cannot yet be read - 17 September 2026
• The Document Foundation: The Politics of Standards - 16 October 2026
• The Document Foundation: LibreOffice 26.8.1 is now available, at last - 8 October 2026
• WHATWG: HTML Living Standard (read 26 October 2026) - 26 October 2026
• WHATWG: FAQ, Living Standards and Review Drafts (read 26 October 2026) - 26 October 2026
• TrustList catalogue: live product listings in the productivity, spreadsheet, presentation, document management and PDF software categories, read through our API on 26 October 2026