OOXML ISO 29500: What the Official Record Says About TDF’s Microsoft Fast-Track Claims

What TDF is claiming​

The post is by Italo Vignoli on the TDF Community Blog. It is a retrospective from an advocacy organisation that competes with Microsoft Office, not a neutral inquiry.

TDF says Microsoft launched Office 2010 implementing the "Transitional" variant of ISO 29500 rather than the approved "Strict" variant. The post also says Transitional is the variant used by Microsoft Office, Microsoft 365 and clones such as OnlyOffice and WPS Office. In TDF's words, Strict is the last and most obscure option in the format menu.

The main allegations, as TDF presents them:

• Fast-track abuse. Ecma International, whose Technical Committee 45 was chaired by two Microsoft employees at the time, submitted a roughly 6,000-page specification in December 2006 through a procedure meant for tried-and-tested documents.
• Technical objections. TDF says Brazil raised more than sixty objections, India contested incompatibility with ODF, France proposed splitting out a "clean" core, and Norway submitted twelve observations.
• Committee irregularities. TDF cites Portugal gaining members who were Microsoft partners. It says Italy's committee grew from 5 to over 80 members, including a law firm and a PR agency working for Microsoft. It says Norway's committee chair resigned in protest, and that Martin Bryan said new members caused procedural votes to fail.
• Spain. TDF says Microsoft wrote to Spain's national body claiming Andalusian government support for OOXML, and that the Andalusian government denied it and complained.
• The Geneva meeting. TDF says delegates were expected to handle thousands of amendments in about a week, and that many had not seen the final text. It says Microsoft staff and partners outnumbered every other organisation roughly ten to one.

These are TDF's claims. I could not verify the national-body objection counts, the committee membership figures, the Spain letter or the ten-to-one ratio against contemporary records. Treat them as attributed allegations, not adjudicated facts.

What the official record confirms​

ISO's own April 2008 announcement gives the outline of the vote.

• ISO/IEC DIS 29500 was originally disapproved in the fast-track vote that ended in September 2007, when 3,500 comments were received. The document does not describe that as a scandal. It says that under JTC 1 rules a ballot resolution meeting followed.
• The BRM was held in Geneva on 25–29 February 2008. According to ISO, the comments had been reduced to just over 1,000 individual issues. Priority items such as accessibility, date formats and conformance were discussed, and the rest were handled by a voting process the participants agreed.
• National bodies then had 30 days to reconsider their votes. That period closed on 29 March 2008. ISO says the approval criteria were met, with 75% of JTC 1 participating-member votes positive and 14% of all national-body votes negative.
• ISO notes that the process was open to national bodies from 104 countries, 41 of them participating members of JTC 1.

So the first ballot did fail, but the rules allowed a resolution process and a re-vote. TDF says the standard "narrowly" passed. ISO's figures show it cleared both thresholds. The official numbers do not speak to TDF's argument about whether the review was meaningful in practice.

A November 2007 FAQ from the SC 34 committee's BRM coordinator, Alex Brown, shows the process was designed to be tight. The BRM was capped at five days, with no virtual attendance, and no press or observers. Comments were to be resolved by agreeing revisions to the text, and that FAQ says a further ballot would not follow. Votes could be changed within 30 days. This is consistent with TDF's picture of a compressed timetable, though the FAQ does not say whether the time was adequate. It also explains why the ODF comparison matters to TDF. The FAQ says ODF needed no BRM because every national body that voted had voted to approve it.

Strict versus Transitional: the Windows-relevant part​

This is the part that affects Office users and administrators today. Microsoft's own archived Office engineering blog describes the two conformance classes. Transitional is meant to preserve the fidelity of existing binary documents being migrated, and it includes many legacy features. Strict is a subset without those legacy features. That makes it theoretically easier for a new implementer to support, but less able to preserve the fidelity of existing documents.

Microsoft's stated reasoning on Office 2010 differs sharply from TDF's. The Microsoft post says the decision to start with Transitional was relatively simple, and that its primary consideration was the needs of its customers. It adds that customers value compatibility because they collaborate across multiple Office versions. The same post says Microsoft also began work toward Strict support once the final text was locked.

Independent descriptions of what shipped when:

• Office 2010 can read Strict but cannot write it. Office 2013 is described as the first version that can read and write Strict.
• Wikipedia says Office 2013 and later fully support Strict but do not use it as the default format, because of backwards-compatibility concerns.
• In Word 2013 and later, the Save As menu offers both Word Document (docx) and Strict Open XML Document (docx).

A caveat on TDF's wording. TDF says Transitional was "rejected by ISO in the September 2007 vote." That September 2007 ballot was on the submitted draft, which preceded the Strict/Transitional split. The Microsoft post says the Strict and Transitional conformance classes came out of the BRM process. ISO/IEC 29500 as published does include Transitional (Part 4). I would not repeat the "rejected" phrasing as settled fact.

TDF's strongest practical point survives that caveat. Strict exists and is selectable in modern Word, but nearly all real-world DOCX, XLSX and PPTX files are Transitional. TDF argues that this undercuts the practical value of the Strict specification. Microsoft's reply is that compatibility with legacy documents was the whole point.

What this means for admins and users​

Be careful about the inference. The historical dispute does not mean every Microsoft document will break in other software. It does show that "ISO standard" on its own doesn't guarantee identical rendering across applications. Most of the compatibility pain comes from implementation differences, legacy features and application-specific behaviour, not from the standardisation history.

Practical steps for IT teams, drawn from general industry practice rather than from the sources above:

1. Test representative documents in the actual applications and versions you use. Complex tables, tracked changes, embedded objects, macros and custom fonts are the usual trouble spots.
2. Keep the original files when migrating suites or converting formats, and check the rendered output before relying on a converted copy.
3. Don't assume that saving as Strict in Word will make documents more portable. Check how your target applications handle those files first.
4. Where long-term archiving or digital sovereignty is a policy goal, evaluate ODF and OOXML on tested interoperability, not on the standard's label.

Balanced assessment​

TDF's argument has real documentary support in places. The 6,000-page fast-track submission, the compressed BRM and the 2008 appeals are matters of record. Its broader point that well-resourced companies can dominate standards bodies is a fair one, and TDF itself says most standards bodies act in good faith. TDF is also a direct competitor with obvious interests. Its post calls the process "manipulated" and "abused" without independent findings, and it leaves out the official explanation of how the BRM and re-vote were meant to work. It also leaves out Microsoft's compatibility rationale for Transitional.

The documented outcome is a failed first ballot, a resolution process, and approval at the end of March 2008 under ISO's stated criteria. Whether that process was fair in spirit is the part still contested. For Windows and Office users, the lasting effect is that two competing document families remain in use, and the label "standard" doesn't settle compatibility questions between them.