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.)