The Standards Blog

Forecast: ISO Will Announce on Tuesday that OOXML Approval has Failed

OpenDocument and OOXML

Updated:  The vote did fail.  Further details are here.

With the polls now closed and the early results in (some public, some not), think it's time to predict with assurance that ISO will announce tomorrow that ISO/IEC DIS 29500, the draft specification based upon Microsoft’s Office Open XML formats, has failed to achieve enough yes votes to gain approval at this time.  This, with all due respect to the contrary prediction of The Old Gray Lady and US Paper of Record, the New York Times.

The final vote has been a moving target for some time, and for a variety of reasons.  In most cases, the dynamism in the vote has been as a result of various types of behavior by Microsoft, both alleged as well as, in some cases, admitted.  In one case, that behavior led to the Swedish national vote being thrown out and replaced with an abstention, after it became apparent that one company voted more than once (Microsoft admitted that an employee had sent a memo urging business partners to join the National Body and vote to approve, and assuring them that their related fees would be offset by Microsoft marketing incentives).

These actions have not only undercut the credibility of the system, but appear to have finally resulted in the sort of backlash that I have been predicting for some time.  In at least one National Body, I am told that what had been trending towards  a "yes" vote swung late last week to a "no," largely in reaction to the pressure that was being asserted against the members of the National Body and the widespread reports of similar behavior (and worse) elsewhere.

While I have repeatedly inveighed against the damage done to the standard setting system during this process, I think that the final vote is a sort of validation for the essential integrity and resilience of that system.  Clearly, OOXML is a specification that was not ready for prime time, and in National Body after National Body, whether they voted yes or no, long lists of comments - some hundreds of pages long - were appended. 

Rather than simply voting "no," these National Bodies played by the rules, and did what they are supposed to do: they took the time (a lot of time, given the length of the OOXML specification), during an unfairly brief period, to do what Microsoft and Ecma should have done to begin with, and didn't: properly vetted the specification to make sure that if it is offered to the world with the blessing of ISO/IEC JTC1, that it has met minimum quality standards to be entitled to bear that designation.

One could easily conclude that this amount of scrutin is more than OOXML deserved: a specification that did not utilize existing standards as it should; a specification that was rammed through with a focus only on speed and not quality; a specification that was promoted using every lever and trick in the book; and finally, a specification that was subjected to voting in many countries under circumstances that made a mockery of alll of the diligent work performed by those that had sweated their way through all 6,000 plus pages.  In contast, the admittedly shorter, but still lengthy ODF specification, which was several years in the making in OASIS, resulted in so few comments that a Ballot Resolution Meeting was not even needed.

Microsoft is now trying to put the best face on the changes that will need to be made, speaking as if this is simply business as usual.  As Microsoft's ever-cheerful Stepford architect, Brian Jones, wrote at his blog a few days ago:

I haven't seen any comments so far that should prove too challenging, but I haven't seen the final list yet. With the number of countries participating I wouldn't be surprised if we got somewhere in the neighborhood of 10,000 comments total. Many of these will be duplicates, but either way there will be a lot of comments to work though. I think that once we hit the ballot resolution meeting in February we'll see a significantly improved spec thanks to all the eyeballs reviewing it.

To speak approvingly of 10,000 comments (with duplicates) as if this was a good thing rather than a source for profound embarrassment is, to me, rather astonishing.  How so many comments will be addressed satisfactorily in a mere week of meetings will be something interesting indeed to behold - as long as one is not tasked with the chore of actually resolving them all.

So there we are.  It's been a long hard road, and we are from the end of it yet.  But this was a crucial, "must have" result, and I think that all of those that have labored so hard for so long to prevent a second rubber stamp of the OOXML specification should take a moment to feel good about what they have accomplished.  If OOXML is ever to become an official ISO/IEC standard, it is far more likely now than before that it will be worthy of that name.

Congratulations - and thanks - to all.

For further blog entries on ODF and OOXML, click here

subscribe to the free Consortium Standards Bulletin


How so many comments will be addressed satisfactorily in a mere week of meetings will be something interesting indeed to behold - as long as one is not tasked with the chore of actually resolving them all.

My read is that Microsoft will prepare two separate revisions and take a three-part strategy:
  1. Hardball: cosmetic revisions only, counting on political pressure to swing the vote
  2. Compromise: as much change as MS can live with without changes to any shipping products or risk of alternate implementations.
  3. Declare the conflicts "irresolvable" and drop the whole thing.
MS' handlers on this seem to be keeping very close track of things.  Well before the end of the "ECMA response" phase they should know whether they have the votes to power through the process (perhaps involving airdropping Steve Ballmer into a few select offices,) which will let them decide whether to take Track #1.  If that doesn't work but matters aren't hopeless, expect Track #2.

However, there will be a deadline where they'll have to decide how likely it is that the BRM could actually report out an IS-29500 that Microsoft can't tolerate -- such as one that references a W3C-style conformance suite.  If it looks like the BRM is going rogue, they'll have to pull the plug.

Alex, I'm not sure I understand what I said that relates to your point.  I didn't say anything about Ecma withdrawing the spec, and the text of my blog entry rather assumes that a cleaner, better version of OOXML will be approved.

In my response to this same topic one comment down from this one, I say:

That is, of course, assuming that it appears that such a dialogue would be productive.  If Microsoft and Ecma come back with a conclusion that there are comments that cannot be resolved, and ISO members believe that they have to be (presumably this would be a discussion that would be held within SC 34), then there is the possibility that the BRM would be cancelled, and the process would then be at an end.

This doesn't imply that Ecma and/or Microsoft would withdraw the spec either.  True, I didn't correct Overshoot on his third point.  But as a practical matter, if Microsoft and Ecma were to simply come back and say "We do not agree to any changes," that would have the practical result, one assumes, of canceling the whole process.  Would anyone really want to waste there time, after all, having a meeting under those circumstances?

  -  Andy

Andy,  Microsoft claimed that they have relinquished the control of OOXML to ISO.  So I guess that the NBs could decide to change OOXML on their own, e.g. to make it more "ODF compatible" as suggested by France and Denmark ?

Microsoft could then choose if they want to be compliant with ISO OOXML, be compliant with ECMA OOXML, or stay with MS OOXML (ie ECMA OOXML with MS proprietary extensions, like macros, Sharepoint tags, proliferation of VML...)  To paraphrase a MS motto : 3 OOXML standards offer more choice than one !  ;-)

Luc Bollen

Actually, Microsoft consistently points out that Ecma will be able to do whatever they want with the spec.  PJ included an interesting comment from Microsoft's Brian Jones a little while ago as a news pick, which you can find here.  In it, Brian allows as how it's unlikely, but that if it happened, Microsoft would not be obligated to make the same patent pledge regarding any material that it had not, itself, offered.

  -  Andy

ARGH, I just wrote my comment, then switched the 'Post Mode' from HTML to POT, and the whole thing disappeared! That isn't normal, surely? Anyway, my question is a followup to what overshoot says. Who is responsible for making changes to the spec, prior to the February vote? Is it Microsoft themselves? Does Emca have any role? My reason for asking, is that if the important comments of the NB's are properly taken into account, then there are likely to be some changes that Microsoft wouldn't be happy with - indeed changes that might negate the whole purpose of OOXML standardization in the beginning. For example, if the backwards-compatibility references are fixed (either by specifying exactly what it means to word wrap in the style of Windows95, or alternatively simply removing all of those weird backwards-compatibility tags), then Microsoft would be left out on a limb. Is this a possible scenario?

Sorry about the loss of text; I'm not sure what happened there.  I tried toggling to POT with this comment (after copying it!), and had no problem.

Regarding your question:  I touched on this in this blog post, noting that the next step is to kick all of the comments back to Ecma and Microsoft.  They'll have until mid-January to mull over each comment, and to propose what to do with it.  Possible responses can be things like, "Disagree - ignore," "Agree - propose this resolution," "Agree, but any effective solution would be infeasible," and so on.  The ISO members generally, and the SC 34 members in particular, will then have a bit over a month to consider these responses and how they feel about them.  Then, at the Ballot Resolution Meeting (BRM), the great debate will begin, one comment at a time.

That is, of course, assuming that it appears that such a dialogue would be productive.  If Microsoft and Ecma come back with a conclusion that there are comments that cannot be resolved, and ISO members believe that they have to be (presumably this would be a discussion that would be held within SC 34), then there is the possibility that the BRM would be cancelled, and the process would then be at an end.

I think that Overshoot did a nice job of reflecting on how the decisions that would need to be made during this period might be made.  Certainly it will be very interesting to watch indeed, and I expect that someone like Rob Weir (who, unlike me, knows what he's talking about when it comes to technical issues) should have some very good insights and predictions to share.

  -  Andy

Who is responsible for making changes to the spec, prior to the February vote? Is it Microsoft themselves? Does Emca have any role?

Technically, ECMA will respond.  Practically, that means that some of the ECMA committee members will take direction from Microsoft since the ECMA committee charter requires them to do so.

Practically, that means that all of the decisions will be made by MS.

I thought that I wouldn't get any work done today, expecting lots of posts regarding this flooding my reading capacity. But it seems that the voting process is still ongoing, or strange things might be happening behind closed doors (which I fear). I'm glad you wrote this, even before having the final results. You always manage to reflect many of the thoughts that I share, and kill many doubts that arise, all in a well worded and concise post. Even then, this one stands out, and I particularly liked the recap of the whole story (sometimes I found myself trying to explain what this is all about, and there are so many faces to it that it gets impossible quickly). Thanks and lets keep our fingers crossed. PD: I'm from Argentina, where the IRAM (our NB) stayed away as much as it could, but I'm hoping our neighbors at Uruguay to be much smarter than us and cast the vote that needs to be cast. nachokb

IIRC, the Commonwealth of Massachusetts requires an open document format for government document interchange. OOXML was said to be an option, but I'm not sure if it was because it was made an ECMA standard or because they had submitted it to ISO for approval.

Given the time limits for implementation in MA and the fact that OOXML won't be an approved ISO standard till Feb. 2008, will it get adopted in MA?


Sad to say, I think that Massachusetts' part in this play is now over.  I don't think that what happens in JTC1 will have any effect on the decisions that have already been made in the Commonwealth.  Fortunately, Massachusetts has already performed the most important service it could have performed by doing what it did, for as long as it did, when it did.

  -  Andy



I'm not sure it's right to see this vote in terms of pass/fail (though it is possible to interpet the Directives this way).

The main purpose of the ballot is to generate comments for the resolution process, and it's that process which will ultimately decide the fate of DIS 29500 with a new text, different voting arithmetic, different voters, and a fresh vote.

- Alex Brown.


While what you say is true, MS failed to get the necessary votes to have the thing pass with flying colours. From a business and marketing perspective that is a failure.

Also, it forces them into seriously addressing all the comments that have been made. It would have been easier to ignore them if everyone had voted yes with comments.

My pennieth and I may be wrong.


Microsoft have failed in their bid to have the standard rubber stamped. From my reading of the rules if there were enough letter ballots at this stage in favor of approval then the SC34 secretariat (ANSI who voted yes) would have had the discretion to call a BRM or declare the process over and publish the standard with no changes and no attempt to address or even read the comments. Now they have the discretion to call a BRM or kick the whole thing out. Microsoft/ECMA don't have a say in this.

Alex, you are certainly right in that regard, and if I implied otherwise in the bost it was not intentional.  What I was trying to say is that having a "yes" vote fail is critical to making the process going forward productive, or at least to the hope of it being productive.  If votes don't need to change, there won't be sufficient incentirve for Microsoft and Ecma to work hard to get those votes to switch by addressing the comments that would make OOXML a better standard.

An abiding concern is whether additional nations will upgrade to P status, thereby diminishing the need to make important concesssions.  If that happens, much of the value of the vote just completed would dissipate.  Given the track record of events to date, that is a real concern for me.

  -  Andy

Microsoft's behavior in pushing OOXML has been nothing short of scandalous. Any attempt to subvert the standards process should be dealt with stringently and organizations that aim to undermine the process should be blacklisted for a few years. Also, organizations like ECMA that submit flawed proposals like OOXML that has wasted so much collective time across the globe should be placed on a watch list. I propose the creation of a "Standards Watch" that monitors the activites of all organizations that seek to contaminate the standards process.

Venkatesh Hariharan

SFS, the Finnish NB, has sent out an email notification that the final ISO result is disapproval. This is, of course, not an official ISO announcement, but I assume they know what they're talking about.

If the provided list is accurate and I count correctly, OOXML has failed by both criteria :
- 32 valid votes by JTC1 P-Members :  2/3 is 21.33, and there are only 17 YES votes --> FAILED
- 69 valid votes by ISO Member Bodies.  25% is 17.25, and there are 18 NO votes --> FAILED

Amongst the 30 "original" JTC1 P-Members : 8 Yes, 14 No, 8 Abstain

Amongst the 11 "late-comers" JTC1 P-Members : 9 Yes, 1 No (Ecuador), 1 Abstain (Trinidad & Tobago)
Amongst the 15 "late-comers" SC34 P-Members : 12 Yes, 0 No, 3 Abstain (Chile, Finland, Trinidad & Tobago)

About a possible vote stuffing : I think that the figures speak for themselves.

Luc Bollen

To speak approvingly of 10,000 comments (with duplicates) as if this was a good thing rather than a source for profound embarrassment is, to me, rather astonishing.

They are of software company. They do have 10k bugs in backlog for more or less every product they have. So they are not surprised nor thrilled. M$ isn't exception. This is happens all the time in software: you cannot achieve perfection - some issues will always remain, some work scenarios will not work as expected, etc.

And the standard developed by software company naturally have all the same issues. Somehow I'm not surprised.

What actually worries me more, is that they plan to fix all this by February. Now we have seen all the dirty ways to play with the system. Till February, M$ has enough time to plant their people in all places, meaning that by then there would be noise - journalists or bloggers - they would silent it all. Next day, we might wake up with news coming out of everywhere that standard was accepted. The possibility really frightens me.


I'm a bit surprised that it seems Microsoft didn't get its way on this vote.  I thought they had already succeeded in subverting the process.

But this is only mildly good news.  Microsoft will not back off and start playing nice.  Remember, they don't want a real standard.  They will continue to do everything they can think of to get their proprietary specification blessed.  Expect more packing of committees, threats, bribes, dirty tricks, and more.  It might be possible to block them all the way, but I have my doubts.  It will be very hard to keep up enough public attention on this for as long as the subsequent process will take.  They will not let up, and probably are counting on the opposition to fade away from that lack of attention.  They may even find ways to keep the issue out of the limelight (perhaps by mounting a diversionary action in some other area). 

I hope I'm wrong.   Perhaps we will be able to block them, but it will only get harder from here on.  Are we strong enough to keep up effective opposition to subverting the process?  I hope so.


If the comments in the BSI wiki are representative of other NBs, at least 90% of the comments will be typographical errors, or otherwise trivial to rectify. In fact, I would expect a revised draft with such errors removed to be circulated fairly rapidly.

I'm sure you're aware of that fact, but it's worth emphasising when talking to journalists. If you make a big play of the "10,000 comments" issue, it would be very easy for the story to become OOXML gains momentum as Microsoft fixes 90% of bugs overnight. The real issue isn't the 10,000 overall comments, but the 10 that will cause real arguments.

The BSI's big arguments are renaming OOXML to RODDL, dropping or justifying the existence of VML, proving that OOXML truly is backwards-compatible (or improving it such that it is), and rewriting OOXML from scratch based on ODF. Leading with these issues will give journalists a more accurate understanding of the process.

- Andrew