TDF Community Blog

All the posts we have dedicated to the OOXML format – and many of those we will dedicate to it in future – analyse the reasons why it is a proprietary format despite having been approved by ISO as a standard, open format. However, they do not address the reasons behind or the details of the standardisation process.

This is a gap we hope to fill with this post, which summarises the events that took place between the standardisation of the ODF format – a standard and open format – and the standardisation process for OOXML, as well as the process itself, which was completely broken in every respect, from methodology to procedure.

Microsoft had begun work on an XML-based document format around the year 2000, with the aim of modernising the obsolete DOC, XLS and PPT formats, which were simply the serialisation (writing) of memory content to disc, and as such were no longer in line with the evolution of Microsoft Office.

The aim was certainly not to develop a standard format, not least because the echo of Bill Gates’ internal memo – “allowing Office documents to be rendered very well by other people’s browsers is one of the most destructive things we could do to the company; we have to make sure that Office documents depend on proprietary capabilities” (slightly abridged version of the original memo) – had not yet died down.

Consequently, during the ODF standardisation process, Microsoft had stated that it would not support the ODF standard format, as it was not in its own interests.

In early 2006, however, the Commonwealth of Massachusetts – one of the historic states of the confederation – announced that it would adopt ODF for all public documents, so that they would be independent of software from a single vendor.

This decision provoked a reaction from Microsoft, which could not tolerate the fact that a US state was adopting a standard, open format developed outside its control, which benefited users rather than its own commercial interests.

The story of the ISO/IEC 29500 “standard”

The battle over the ISO/IEC 29500 “standard” – the ISO standardisation of Microsoft’s Office Open XML format between 2006 and 2008 – is a perfect example of a broken standardisation process.

It is not an exceptional case, but it has been thoroughly documented and offers important food for thought for all those who continue to maintain that the OOXML format is a standard.

The story began in December 2006, when Ecma International – whose Technical Committee 45, responsible for the project, at the time was chaired by two Microsoft employees – submitted the OOXML specification to the ISO/IEC JTC1 (Joint Technical Committee) of ISO/IEC for adoption as an international standard under the “fast-track” procedure, designed for tried-and-tested specifications requiring only administrative ratification.

The decision to submit a 6,000-page specification – one of the longest ever submitted to ISO – via a process designed for short and fairly well-established documents had a decisive impact on the nature of the review to which the standard was subjected.

In September 2007, the proposal was rejected by ISO members due to votes against it or substantial technical objections to its approval. Brazil raised more than sixty technical objections regarding the use of non-standard date formats and inadequate language support. India contested the incompatibility with the ISO ODF standard. France proposed splitting the specification into a “clean” core and a compatibility layer for pre-existing systems. Norway submitted twelve specific technical observations.

These concerns were not mere complaints but went to the heart of the matter: namely, whether the OOXML format specifications could meet the fundamental requirements of an international standard.

Issues at national standardisation committees

What followed this vote was the subject of appeals by numerous national standardisation bodies. In many countries, there were widely documented reports of serious irregularities in the composition and conduct of the national technical committees.

In Portugal, new members appeared, the majority of whom were identified as Microsoft business partners. In Italy, the number of members rose from 5 to over 80 in just a few months, and among them were one law firm and a PR agency working for Microsoft on topics that had no connection whatsoever with the document formats, and several Microsoft business partners.

In Norway, the committee chair resigned in protest.

Martin Bryan, coordinator of the ISO working group, stated publicly that the influx of these new members, whose sole interest was to speed up the OOXML approval process, had caused several important procedural votes to fail.

Microsoft sent an official letter to the Spanish national body claiming that the Andalusian regional government supported OOXML, a claim which was promptly denied by the Andalusian government itself, which also lodged a complaint.

As interested observers of the process, and as members of various national standardisation bodies, we can add that all this stemmed from the head-to-head competition between Microsoft and IBM, which at the time were focused solely on competing with one another on the basis of their financial strength and completely ignored the interests of users – a situation that is now penalising us at every level.

Had the two companies invested the same energy in developing a cross-platform standard format, building on what had already been approved – namely ODF – and improving those parts where it was not yet fully developed, instead of filling the committees with “relatives and friends”, we would be in a completely different situation today, and we would not have to fight for our digital sovereignty.

The Ballot Resolution Meeting in Geneva

In February 2008, the Ballot Resolution Meeting (BRM) was convened in Geneva, during which representatives of national bodies were expected to examine the thousands of proposed amendments to the 6,000-page document in just one week. An unachievable goal.

Many national bodies reported that they had been unable to examine the actual text on which they were supposed to vote, as the final version of the specification had not been submitted. The BRM coordinator, Dr Alex Brown, subsequently stated publicly that failing to make the final text available to national bodies during the appeal period had been irresponsible.

The standard was approved in April 2008, narrowly meeting the required threshold. Appeals lodged by South Africa, Brazil, Venezuela, India and other countries against procedural irregularities were rejected by the ISO Technical Committee. A post-approval analysis revealed that, during the BRM, Microsoft employees and “partners” outnumbered representatives from every other organisation by a ratio of approximately ten to one.

The OOXML format today

Microsoft launched Office 2010, implementing not the approved “Strict” variant of ISO 29500, but the earlier “Transitional” variant rejected by ISO in the September 2007 vote, which had been deemed unsuitable for use in new documents. Alex Brown, the BRM coordinator who had overseen the approval, publicly accused Microsoft of acting in bad faith.

The “Transitional” variant of the OOXML format is the one used by all users of Microsoft Office and Microsoft 365, as well as by clones of the two suites such as OnlyOffice, WPS Office and Euro-Office. The “Strict” variant has disappeared from discussions and is the last – and most obscure – option in the format menu.

The responsibilities of standardisation bodies

The case of the ISO 29500 standard demonstrates that standardisation processes, however well designed, can be manipulated by companies with sufficient resources and motivation.

The fast-track procedure was abused. The composition of the national committee was manipulated. The procedural rules were interpreted in such a way as to favour the proposer. The sheer volume of the specification made a genuine technical review by independent experts practically impossible within the available timeframe.

Following approval, a variant of the standard different from the one approved was implemented, without any consequences. Indeed, we can legitimately argue that the advantages the company derived from this failure to comply with the standard were actually rewarded by the market, and were not sanctioned by any authority at any level.

The conditions that allowed ISO 29500 to develop as it did – the concentration of resources, the decisive influence of commercial strategies and objectives, and the asymmetry in investment between large and small companies – were not addressed by the reform of the JTC1 “fast-track” procedure following the OOXML scandal.

Standards bodies are, nominally, neutral arbiters – forums where conflicting interests negotiate shared solutions – but in practice their neutrality is always contested and never guaranteed.

The companies that invest most heavily in the standardisation process – sending more representatives to meetings, funding the secretariats, and having the resources to comment exhaustively on every draft – are also those that exert the greatest influence over the processes.

This does not mean that standardisation bodies are subject to pressure or corrupt, as most operate with a sincere commitment to their mission.

It does, however, mean that the conditions underpinning good standards are not automatic, but require the active participation of various stakeholders – governments, civil society organisations and the academic community – whose interests are not aligned with those of commercial companies, as well as a set of rules that prevent any single company from dominating the process.

Above all, they require a culture within the standards community that takes the principles of reusability, transparency and genuine interoperability seriously as values, and not merely as rhetorical, superficial commitments, which conceal specific commercial strategies.

Standards are technical documents drafted by engineers and discussed in committees before being implemented in code. However, to discuss them only in technical terms would be to overlook an essential aspect of their nature and function.

In fact, standards are also – and above all – political tools because they define market players, determine the direction of development, and establish the interests served by the ecosystem. In other words, they underpin the market’s power relations.

What a standard does

A standard is a coordination mechanism that allows multiple independent parties, such as software developers, hardware manufacturers, content creators, governments and businesses, to collaborate without having to negotiate the terms of their interaction every time.

Like a language, a standard enables communication with everyone who speaks it. It is an immensely valuable promise of universal communication, which is why standards are so important in computing, where the network effects of compatibility multiply rapidly.

However, a standard also defines the conditions for participation.

A simple, transparent standard based on widely available knowledge can be implemented by multiple parties without creating inequality.

In contrast, a complex, deliberately obscure standard that requires specific expertise can only be implemented correctly by those who defined it, creating inequality.

Therefore, the complexity of a standard acts as a barrier, determining who can access the market and the balance of power within it.

Open ecosystems

An open ecosystem does not depend on a document containing the specifications of the standard, but rather on any stakeholder’s ability to implement the standard fully and correctly in accordance with the specifications, without resorting to undocumented behaviour or reverse engineering.

This requires the specifications to be written clearly, to allow for only one interpretation, and for the standard not to depend on behaviours defined by the reference implementation, which would make the latter a mandatory dependency. It also requires the standard to be stable enough to prevent compliant implementations from becoming obsolete due to silent revisions.

When all these conditions are met, the standard can be implemented by anyone, even those who played no part in its creation. Universities, small businesses, open-source communities, government agencies, and individual developers can all produce compliant software.

Competition is possible based on the quality of the implementation rather than proximity to the standard’s authors or reverse engineering. The standard provides a foundation upon which anyone can build.

Closed ecosystems

While the closure of an ecosystem through a standard may be accidental, it is usually intentional and based on a series of fairly easy-to-list mechanisms.

The first mechanism is unnecessary complexity. When a standard defines its own solutions to problems that already have valid, widely implemented solutions, it forces other players to reinvent the wheel. Every proprietary subsystem is a new element that increases costs and often artificially limits compatibility.

The second mechanism is underdetermination. When specifications are ambiguous or limited, different implementations produce different results. When a document is displayed slightly differently, users always blame the second application rather than the format. This is an extremely insidious form of lock-in.

The third mechanism is extensibility. If the specifications permit the addition of proprietary extensions, the document is technically compliant with the standard, but only one programme can display it correctly. In this case, the standard merely covers a proprietary system.

In addition to these three mechanisms, there is direct or indirect influence over standardisation bodies. Direct influence occurs when the vendor can influence the standardisation process itself, shaping the compliance requirements to match the behaviour of their own application. Indirect influence occurs when the vendor can influence other members through factors external to the standardisation process.

The stakes beyond software

The consequences of open and closed standards affect more than just software developers.

For example, a government that archives its documents in a format that can only be handled correctly by a specific piece of software is, in effect, dependent on the vendor that developed it. This means that the long-term preservation of public documents is subject to the commercial decisions of a private company.

Cultural institutions, such as libraries, archives and museums, face the same problem over longer timescales. An open, standardised format is more likely to remain readable over time than a proprietary format whose continued support depends on the strategic priorities of a single supplier.

For developing economies and public-interest organisations with limited resources, open standards provide a vital infrastructure that ensures equal access.

Reading the technical as political

When evaluating a standard, technical details become political.

Using #RRGGBB for colours rather than a proprietary system is not an aesthetic choice; it affects who can implement the format and who benefits from the ecosystem it creates.

Adopting the ISO 8601 standard for dates rather than a serial system inherited from a single piece of proprietary software based on a fifty-year-old bug is choosing interoperability over continuity with a proprietary past.

These choices add up.

A standard that consistently aligns with open and established practices rather than proprietary reinvention on the basis of multiple decisions of this kind is fundamentally different from a proprietary format that constantly does the opposite, even though both produce documents that appear identical on screen and both bear the label ‘open standard’. This label means very little.

What matters is whether independent implementers can develop fully compliant software and whether the ecosystem is genuinely accessible to all who wish to participate. Ultimately, the standard must serve the interests of users rather than the company that defined it.

These are political issues which deserve to be discussed as such.