Should OOXML be a national standard?

Strict OOXML: probably not; Transitional OOXML: surely not?

By Rick Jelliffe
August 10, 2009 | Comments: 3

I am not of the school that says that because Microsoft Office dominates the office suite market and its sub-markets so effectively ODF is a quixotic and ineffective sideshow, and merely a transparent grab for importance by parties who have been unable to prevent their own products' marginalization by the legitimate means of product quality, features and value.

But neither am I of the school that says that ODF and ODF products are necessarily and immediately substitutable for all uses of OOXML and Office.

This is why I supported both the ODF and the OOXML technologies being written up as international standards. An international standard for IT is like a book in a library, to be selected and evaluated by users where appropriate. All care and no responsibility: you betcha...the standards committee is not in a position to dictate policy or regulation or to guess every possible application.

However, national standards are much closer to procurement and national policy. So there is no inconsistency in ajudging that a particular technology would be usefully written up as an international standard but yet not appropriate for a national standard. And vice versa.

I was recently asked by some open source colleagues about my opinion on the move in a particular country to get OOXML adopted as a national standard. I was not aware of it, but my more considered answer is along the lines of well, it depends on what concrete objectives are being aimed for, and whether standardization as a national standard would in fact deliver those objectives. I don't know enough about national requirements for any country, including my own, to have much of an opinion; and it is not my place in any case.

But I do have some thoughts that generally bias me against national standardization of OOXML, or at least, against national standardization of OOXML's Transitional dialect, in the absence of having heard any particular positive case.

My support of OOXML was largely predicated on it being a practical method of getting OOXML documented and reviewed, with IP issues clarified, and with Microsoft brought to the table and reconciled to trying to find out how best to use the system rather than ignoring or beating the system. This is being fairly well achieved by the international standard effort at SC34 in cooperation with ECMA, and I don't see that national standardization efforts for OXOML add anything of value to that.

And, in any case, national bodies looking to standardize ODF and OOXML with a view to making things better for government and procurement should seriously consider standardizing the imminent versions of these rather than the current (mid 2009) versions: both ODF 1.2 and the revised OOXML should be out by early 2010. These have significant changes from the point of view of standardizers: if passed, ODF 1.2 will have spreadsheet formulae more adequately specified, and if passed the new OOXML will have its Strict dialect in a new namespace, What is the big hurry? Marry in haste, repent at leisure!

It is this last aspect of the pending update to IS29500 that national bodies discussing cloning IS29500 as a national standard should nut out: IS 29500 has two dialects, one is a transitional dialect which is a kitchen sink, but it also has a strict dialect which contains many of the improvements required by the national bodies at the BRM as being the minimum required for acceptable usage.

It is certainly possible for a national body to transpose IS29500 parts 1 (Strict), 2 (OPC) and 3 (MCE), but to decide not to transpose part 4 (Transitional). In the same way, it is possible for a procurement policy to allow OOXML, but only OOXML that accords with parts 1, 2 and 3.

To my mind, It would be inconsistent for a national standards body to have required changes to OOXML during the ballot that were addressed only in the Strict dialect which were enough to change its "no with comments" vote to "yes", yet to adopt IS 29500 part 4 as a national standard. If a feature was so bad that it needed a workaround then, what makes it acceptable now?

In fact, making Transitional OOXML a national standard would seem to me to have many negative aspects: in particular, we want to encourage Microsoft down the road that relegates transitional documents to legacy. We want Strict OOXML to be the forward-looking dialect of OOXML, even if we also want ODF to be the default exchange format for public data.

Put bluntly, the provision of Part 4 Transitional OOXML should not be an excuse for avoiding the changes required by Part 1 Strict OOXML. Transitional OOXML was provided as an on-ramp, and the corrections to OOXML underway will finally make that on-ramp useable. But it is still an on-ramp and Strict OOXML is the highway that the NBs voted for at the BRM. Transitional OOXML should not be encouraged as a standard for future documents, and I think this is fairly clear from the decisions of the BRM. I think national bodies would be prudent to take this into consideration as part of their deliberations.

(I should point out again that the long-term position needs to be documents in which, by allowing multiple formats simultaneously in the fashion of MIME mail which allows HTML and text forms of mail, the particular details of format are less critical. It may be important to decide whether oranges are absolutely better than apples if you can have to choose only one, but less important if you are making a fruit salad.)


You might also be interested in:

3 Comments

@Rick

Except where there's a need for translation I think transposition of International Standards into National ones is largely a relic of the past (and the need for NBs to make money selling paper copies of these transposed standards). If the International text is usable - use that.

I completely agree that the "strict" flavour of 29500 is where we should all be heading, and I suspect MS will arrive there with the next-but-one version of Office. Maybe other vendors will beat them to it. Personally I am also keen to see the "transitional" flavour kept as an "on ramp" only, and stop any innovation happening there.

- Alex.

Alex: I have been told of at least one country where IS 29500 is indeed being proposed for adoption as a national standard without translation being involved, just as is happening with IS 26300.

I suspect that the next-but-one is probably simply not good enough for many NBs. But where IS29500 Transitional was adopted for use in new documents, it would give it a traction that rather goes against the thrust of the BRM.

@Rick

> I have been told of at least one
> country where IS 29500 is indeed being
> proposed for adoption as a national
> standard without translation being
> involved, just as is happening with IS
> 26300.

Yes, it happens. Can't see a sensible reason for it, myself.

On Transitional, I agree ... a new application that uses the Transitional flavour of 29500 directly violates the explicit intention, agreed by the BRM, for that format to be a "dead language". Still, that is what the upcoming version of MS Office will do.

It will be interesting to see what happens.

- Alex.

News Topics

Recommended for You

Got a Question?