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.