There has been much rejoicing recently at the process whereby, apparently, an ISO committee takes full control of OOXML. But you know, that story is entirely irrelevant. It will have no effect on what implementors of OOXML, including Microsoft, should or will actually do. The story’s ending will I think be mostly tawdry. Oh, and I have some OOXML news that I think is important, but that I don’t think anyone else has reported.

First, a bit of back-story.

What ECMA-376 Is · Microsoft XMLified the internal file formats of the most recent Office release and cooked up a specification with the help of some, um, “partners”, and took it to a standards-organization-for-hire, the result being ECMA-376.

The result is not a particularly good XML document format, and ECMA-376 is not a very good specification, but it has a really important virtue: it describes the format you need to read and write to interoperate with an office suite that Microsoft ships 70 to 100 million copies of every year; there are a lot of ’em out there.

What OOXML Is · The ISO process, brutal and corrupt as it was, has been covered to death by everyone. Its output, soon to be known as ISO/IEC 29500, differs from ECMA-376 in two ways.

  • There has been a substantial amount of cleanup of things that were specified in an ugly or broken or stupid way in ECMA-376.

  • There has been a bunch of XML markup added, which is blessed by ISO/IEC 29500 but not ECMA-376. We need a name to talk about this new stuff; let’s call it “The ISO Delta”.

The ISO Delta · The important thing is this: The ISO Delta is completely irrelevant to the marketplace. It is not implemented in the shipping Microsoft products. Microsoft may choose to implement some portion of it in some future release of some product, or they may not. Given Office’s release and adoption cycle, it’s very unlikely that any pieces of the delta they decide to implement will be widely deployed in anything less than five years.

Thus, if you write OOXML software and you generate ISO-Delta markup, it won’t be usable by the deployed base of software. In fact, we have no information as to how gracefully Office will react; will it bypass such markup or explode messily? I’m not optimistic. So, implementors should not generate ISO-Delta markup.

Implementors also need not bother reading ISO-Delta markup, because it is entirely absent in the deployed base of documents, which in fact conform to ECMA-376.

But Isn’t the Delta an Improvement? · Yes, but that’s irrelevant. If what we want is a good XML Office Document format, we already have one, in the form of ODF. OOXML isn’t interesting for reasons of quality or innovation, it’s interesting because it maps onto this huge existing inventory of high-value documents. Well, except to the Delta, which doesn’t.

Spotting the Delta · So, since ECMA-376 is mostly a dead letter now, implementors have a problem. How are they going to spot the ISO-Delta pieces which they can safely ignore, and focus on the ECMA-376 pieces which correspond to reality?

Well, it turns out that this is covered. I’d like to reproduce one of the resolutions adopted by the BRM:

Resolution 21: The BRM decides to instruct the Editor to incorporate an informative specification of the following, with a reference to it from the Scope:

  • All XML elements which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006

  • All XML elements which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006

  • All XML attributes which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006

  • All XML attributes which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006

  • All enumeration values which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006

  • All enumeration values which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006

  • All simple types which appear in ISO/IEC 29500 but do not appear in ECMA-376:2006

  • All simple types which do not appear in ISO/IEC 29500 but appear in ECMA-376:2006

This was originally my idea. Actually, my original idea was that ISO should simply accept all changes which represented corrections to ECMA-376, and reject all those which constituted enhancements, since they’d be irrelevant for the reasons listed above. I couldn’t sell that, but there was pretty well no resistance to Plan B, which was to at least make the ISO Delta obvious. I (and, I think, the community of implementors) owe thanks to my colleagues on the Canadian delegation, and to Brian Jones and Jean Paoli of Microsoft, for getting behind this and cleaning it up, and to Alex Brown, for deftly making sure it got a chance, at the last possible moment, to be voted in.

It’s Kind of Sad · The coverage suggests that future enhancements to 29500, as worked through by a subcommittee of a subcommittee of a standards committee, are actually going to have some influence on Microsoft. Um, maybe there’s an alternate universe in which Redmond-based program managers and developers are interested in the opinions of a subgroup of ISO/IEC JTC 1/SC 34, but this isn’t it.

I suppose they’ll probably show up to the meetings and try to act interested, but it’s going to be a sideline and nobody important will be there. What Microsoft really wanted was that ISO stamp of approval to use as a marketing tool. And just like your mother told you, when they get what they want and have their way with you, they’re probably not gonna call you in the morning.


Comment feed for ongoing:Comments feed

From: Thomas Koch (Apr 16 2008, at 01:41)

Is it possible, that MS won't be allowed to claim that they implement ISO/IEC 29500, because they don't implement the delta?

Then MS-Office would still not be an office suite based on an ISO standard...?!?


From: Emanuele Vulcano (Apr 16 2008, at 04:13)

A comment on the form and not on the content: your Mad World reference in the last paragraph, intended or not, hit me like a brick. :)


From: James Justin Harrell (Apr 16 2008, at 07:09)

I've heard multiple times (usually on Slashdot >_>) that Microsoft Office 2007 doesn't conform to ECMA-376. How true is that? How difficult is it really going to be for OOXML-supporting programs to interoperate with Microsoft Office?


From: Arnaud Le Hors (Apr 16 2008, at 07:39)

Hi Tim,

I see that we are in total agreement as to what to expect from Microsoft at this point.

If you haven't seen it yet, you might want to give my post on "What Microsoft’s track record tells us about OOXML’s future" a read:

It was written before the vote ended but is still totally relevant.



From: Inigo (Apr 16 2008, at 13:47)


I haven't checked very many MS Office 2007 documents, but those that I have checked conform to Ecma-376. If you have a copy, then you can check conformance to some extent yourself by saving a document from Office and validating it against the Ecma-376 schemas. I haven't tested with documents that, for example, contain macros.


Microsoft can, I imagine very easily, convert Office so it conforms to the ISO 29500 Transitional conformance class, and I expect it will do so very soon. The changes that Tim's referring to as the ISO Delta are all in the ISO 29500 Strict conformance class. It remains to be seen whether this distinction is important for government procurement, and whether Microsoft will change Office to conform to it.


From: Tony Fisk (Apr 16 2008, at 16:43)

It was, indeed, all about having something to dominate the 'open' market.

It remains to be seen how well they can market an ex-parrot with an 'ook' smell.

('Scuse the culture jamming. Your view of things is far more balanced than mine. At least you attempted CPR and tried to keep it as something living)


From: Paul Cotton (Apr 16 2008, at 18:17)

With regards to Arnaud Le Hors's suggestion that Microsoft does not track standardized specs in his blog post on ""What Microsoft’s track record tells us about OOXML’s future", I would like to suggest that your readers check out Michael Champion's blog post entitled "Web Services Standards and .NET Interoperability" at

Michael's post outlines the history of Microsoft's commitment both to implementing the early versions of the web services specs AND then to shipping software that implements the standardized versions of these specs.

In addition as Michael points out, Microsoft remains active in working with other vendors to ensure that we achieve interoperability of the standardized specs even after then have been ratified.

Maybe the "alternative universe" that Tim wondered about actually exists?



From: Robin (Apr 17 2008, at 02:49)

@Paul: and in in the opposite corner we have Internet Explorer...


From: Peter Flynn (Apr 17 2008, at 05:11)

"[...] this huge existing inventory of high-value documents"?

Huge existing inventory, for sure. High-value? I think not. 99% of office documents are ephemeral, whether they're in ODF, OOXML, .doc, or .wp4 format -- especially when they can't be re-used without human eyes to interpret them.

We all know it's polite to flatter the clients by telling them how valuable their documents are, but in reality the dross-to-gold ratio is scarily high.

ISO OOXML justs make it easier to justify continuing the trend, which is fine. The users who have seriously valuable documents are already using other methods.


From: Andres Villarreal (Apr 17 2008, at 05:12)

The big issue about compatibility is not whether a reasonably written text made with a reasonably new text editor will be translated easily between OOXML, ODF, old MS Word and other formats.

The big issue is about documents that use arcane features, that were written for a specific combination of fonts, printers and programming quirks of a specific editor or were fine tuned by trial and error until they worked one time.

The latter is also true for all other types of office documents.

Therefore, the test of making a simple document and checking the representation is good only if your document is really large and nauseatingly complex.

One of the big problems with OOXML is its pretension of standardizing all the MS Office old bad habits.


From: Andres Villarreal (Apr 17 2008, at 06:18)

The Open Software community should create a test suite to check the compliance of an office suite to OOXML, so that any government or organization that expects its procedures to be standards-compliant can check whether Microsoft or any other provider has a true standards-compliant OOXML implementation.


From: Paul Cotton (Apr 17 2008, at 09:22)


Actually I think the IE team is no longer in the "opposite corner". See "Compatibility and IE8" at



From: Paul Cotton (Apr 17 2008, at 21:51)


You might be interested in reading Alex Brown's blog at,guid,3e2202cd-59a3-4356-8f30-b8eb79735e1a.aspx about a simple test of an existing Office document (the DIS 29500 document itself) against a set of Relax schemas that reflect the BRM decisions.



From: eduardo (Apr 17 2008, at 13:34)

to Paul Cotton

Huh? You mean you never heard of "embrace, extend, extinguish?"


From: Jeff Mischkinsky (Apr 17 2008, at 20:36)

... and past performance is not a prediction of future performance:


From: Jomar Silva (Apr 22 2008, at 16:23)

I've spend my last days at FISL (, the biggest free software event of Latin America and I simply could not answer 4 basic questions (and I'm shamed, because I was at BRM):

1-When the final version of IS 29500 will be available ?

2-When Microsoft will support it?

3-If my company wants to adopt it right now, which software I should use ?

4-If I migrate my documents to Office 2007 format now, shall I need to migrate them again ? When ?

Those questions comes from journalists, students and several IT managers and CIOs.

How do you answer to that "4 pearls" Tim ?

The only answer that I gave them (and the only one acceptable, at least to me) is: Adopt ODF...

If Open Document Formats was born to prevent the fragmentation, what we all earn with OOXML ?


author · Dad · software · colophon · rights
picture of the day
April 15, 2008
· Technology (77 fragments)
· · Standards (19 more)
· · XML (135 more)
· Business (106 fragments)
· · Microsoft (19 more)

By .

I am an employee
of, but
the opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.