Some thoughts on OOXML

<< 2008-03-27 13:55 >>

The printed OOXML spec (from Pavel Janik)

I joined ISO's subcommittee 34 (JTC1/SC34) in 2001 to work on Topic Maps, and was somewhat bemused when OOXML burst upon the committee in 2007. I had more than enough to work on with Topic Maps, and so tried to stay as far away from OOXML as possible, since I sensed that it would be easy to pulled into spending lots of effort on this without really achieving anything. Now the story of OOXML in SC34 is approaching the moment of truth, however, and so I've been forced to make up my mind. Having done that, I figured I would have my say on the subject once and for all. (And I'd like to point out that this is my personal opinion, and very much not that of my employer.)

An old dream come true

For an old SGML hand this whole discussion has been kind of odd, because back in the 90s getting Microsoft to move MS Word over to a standardized SGML format was something of a holy grail for the SGML community. Many people spent lots of time and energy trying to educate users on the benefits such a standard would have for everyone concerned (except Microsoft, of course). What's funny is that many of these same people are today opponents of OOXML, which really, in one sense, is that old dream come true. But, as so often happens, this dream looks very different now that it has become reality.

The fast track process

OOXML was initially approved as an ECMA standard, and then submitted to ISO for its fast track process (see also this), which is intended for specifications already approved by other standardization bodies. The assumption underlying the process is that since another standardization body has already approved the standard it should be of sufficient quality that no more than minor tweaks are necessary before it's approved as an ISO standard.

The trouble with OOXML is that it has proved to be an exception to this rule. It's not just that the document itself is monstrously huge. The current OOXML format has a number of technical problems, which have been listed in detail elsewhere. Another problem is that the specification itself is not written as a standard, but more as the sort of technical documentation you'd expect to find for a commercial product. This will cause serious problems for interoperability in practice, and since interoperability is the whole point of a standard, that's not acceptable.

The fast track process proved unable to resolve these problems (1 2),which is not surprising, given that it was never intended to do the kind of in-depth revision that's necessary for OOXML. For this reason, I personally feel that OOXML should not be approved as an ISO standard. It's just not good enough, and it's hard to see that users will lose anything by this, given that OOXML is already published as an ECMA standard, so the current flawed specification is a standard already.

What is to be done?

ISO has in a sense put itself in an awkward position here by already approving the rival OpenDocument format as an ISO standard. This makes it harder to reject OOXML, and at the same time makes it difficult to approve OOXML, since it competes with an existing ISO standard. Generally, I'm unhappy with how closely these two standards are tied to existing software. What I would really have liked to see was for OpenDocument and OOXML both to be dropped, and the two communities to sit down and work out a common agreed format that is not tied to any existing software. The Chinese UOF format, for example, might have served as the starting point for this. ODA has also been suggested. Unfortunately, this requires a political will that does not seem to be present, and so this seems unlikely for now.

An alternative scenario, as pointed out by the Australians, is for Microsoft to resubmit OOXML through the normal standardization process, instead of the unsuitable fast track process. This would allow a process whereby the many wrinkles in the standard could be ironed out, something that was just not possible on the fast track. That specification could then be published, and the marketplace would just have to live with the OpenDocument/OOXML competition. At least it would be easier (with a properly written OOXML specification) to write converters and to add support for both formats in tools. And maybe the marketplace would at one point pick the one over the other, which would be a relief.

Personal note

I'd like to add a personal note at the end here. I've worked in ISO for seven years now, which means that during that time my employer has paid money to Standards Norway to be a member, it's paid for my time to participate in meetings and write the actual standards, and for my travel costs. At the end of this, we can buy the standards we ourselves have written on paper from the ISO shop just like everyone else.

Of course, we also get to vote, but it's not so that the members of Standards Norway vote, and SN then automatically follows the majority. What happens is that SN consults the members and then votes. So on standards that Standards Norway does not care about the will of the members is followed automatically, and this has so far has been the case for everything except OOXML. On OOXML, there is a possibility that Standards Norway might vote differently from what the majority of the members want. What they are going to vote and how they decide is up to them, and I really have no idea how they are approaching this. So while I hope they do listen to their members, a majority of which appears to be against approving OOXML, they are under no obligation to do so.

This, if anyone is wondering, is the background for a subset of the members of the committee sending Standards Norway an open letter setting out their opinion on OOXML, in the hope that Standards Norway will listen. Which they may. Or they may not.

Similar posts

Comments

eivind - 2008-03-27 17:28:17

Nice write-up, Lars. I sincerly hope SN really does the Right Thing.

Jirka Kosek - 2008-03-28 11:09:43

Hi Lars Marius,

OOXML specification from Pavel Janík is not printed, it is just fake made from blank sheets of paper. There is real one http://xmlguru.cz/2007/07/czech-comments-ooxml ;-D

Lars Marius - 2008-03-28 11:16:09

The scoundrel! I see now that he admits his fraud in another blog posting. No wonder he allowed me to use the picture. :)

Robert Cerny - 2008-04-07 03:53:02

As already discussed with Patrick Durusau over lunch in Oslo last week: why not use XSLT to create a bridge between both formats? He said it should be possible. If it indeed is possible, it should be fairly easy for vendors to support both formats.

Lars Marius - 2008-04-10 07:18:53

I'm not sure XSLT would suffice, actually, because some of these formats contain sublanguages (such as Excel formulae) that you can't necessarily translate with XSLT. In any case, this is being worked on: http://www.itscj.ipsj.or.jp/sc34/open/1026c.htm

Add a comment

Name	required
Email	optional, not published
URL	optional, published
Comment
Spam	don't check this if you want to be posted
Not spam	do check this if you want to be posted