I am delighted to see that the free site for ISO publicly available standards finally has the OOXML standards available:
ISO/IEC 29500-1:2008 Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 1: Fundamentals and Markup Language Reference
ISO/IEC 29500-2:2008 Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 2: Open Packaging Conventions
ISO/IEC 29500-3:2008 Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 3: Markup Compatibility and Extensibility
ISO/IEC 29500-4:2008 Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 4: Transitional Migration Features
These standards are useful for several reasons:
1) They provide very detailed, public and usable information about the information exchanged by Microsoft Office products (Word, Excel, Powerpoint) including information that was discovered and disclosed during the process. For example, the exact conversion factors used in Excel for fluid measures. Public information needs to be free, and no tied up in mysterious or encumbered formats.
2) It will be the format used for the next generation of Office software. Trivial changes from the ECMA 376 specification (which is, excluding any minor SNAFUs, the native format of Office 2007) that were required by the ISO review process (changes I regard as completely bizarre) means that Office 2007 does not currently generate conformant IS29500 in a couple of trivial areas (e.g. "yes" must be "true" or "1".)
3) The splitting out of features into transitional and non-transitional has substantially cleaned up the technology, and reduced the barriers of implementation and conversion. For example, the original drafts had two drawing languages, the out-going VML and the in-coming DrawingML: VML is now clearly marked as transitional. In this, IS29500:4 goes much further than ODF (either IS29300 or ODF 1.n) in that ODF does not provide details of its transitional keywords (it seems to regards them as legitimate proprietary, backroom or future business): these include more exact details of how Word treats a bug relating to constant-width whitespace characters in one version of a more-than-decade-old version of Word released in Japan (a feature that was treated as being essential information by opponents of OOXML around the world, notably not including the Japanese themselves.)
4) The ISO process has resulted in hundreds of improvements to the actual technology. For example, Excel gets a mathematically proper version of the CEILING() function. Market dominating information techology is too important to be without any national scrutiny and input: too important to be left to the marketing and technical departments of the vendors or developers, too important to be left to industrial consortia which require vigilance to prevent them from becoming cartelized or dominated by single players; too important to be left to US dominated schedules and committee culture; too important to be left to mob campaigns; only the international standards organizations have the necessary organization, discipline and reach to function even half-well here (and by necessary I do not mean sufficient!)
5) The standards provides a more adequate basis for a future converged office document standard. Whether it is called ODF 2.0 or some new name is not important. There needs to be a lot more debate and consideration of the nature of such a standard: the naive idea that an insufficient technology could be adopted as the sole standard even though it patently did not support the features required by the market dominating products (and putting aside any issues of whether ODF 1.0 and Office 2007 could have been better aligned, which is a different issue.) For example, as part of the CEILING() improvement mentioned above is a clear route to adding prefixed library indicators to function names (e.g. ISO.CEILING() is the correct-behaving function) which in turn decouples the functionality from the syntax: the availability of such libraries is surely a pre-requisite for interoperability between the mooted Open Formula language of ODF 1.2 and the OOXML formula language of Excel.
6) The standards provide information which can be used to improve ODF whether or not Microsoft is at the ODF table, even by cherry-picking.
7) The standard brings Microsoft to the table. It shows they are aware that standards participation and conformance is a cost of doing business now: part of the cost of openness. This will be a tremendous challenge for Microsoft, especially for their development and marketing teams, because they must adopt a conciliatory not regal attitude to changes and limitations suggested by the outside. It means that they must refrain from trying to "pull a swifty" (do non-Antipodeans use that?): I was not at all happy for example that the upcoming Office 2007 service pack does not include IS29500 support (just to reduce the need for updates when the next Office comes out) however I don't see harm in spending more time getting IS29500 reviewed more.
And on that subject, now is the time for interested parties to review the standard and make suggestions for further improvements. National Bodies should have already checked that their edits were in fact incorporated correctly. In particular, issues that were dealt with at the BRM by accepting the Editor's responses but which did not get discussion time can be raised again.
JTC1 is the joint committee of ISO and IEC that looks after Information Technology. Fonts, file formats, programming languages, that kind of thing. SC34 is the committee of National Body delegations that looks after Document Description and Processing Languages. They have two working groups, WG4 on OOXML and WG5 on OOXML and ODF convergence that will have a formal meeting in Okinawa in early February. (I would really love to make that meeting: even though it is winter on that side, Okinawa is close to Japan, Korea, China, SEA, and about the same time zone as Australia and NZ. It is a beautiful place with its own culture and language, and an intensely sad history.)
People wanting to do such a review so that their issues can be on the list for WG4 need to move fast. SC34 normally has rules that substantive issues must be raised 6 weeks before meetings, to give time for National Body experts (especially from non-English countries) to study, discuss and form opinions. So that really limits things to before Christmas. If you, like me, don't have a national body with a committee on this issue, I am sure there are other National Bodies who have committees that will accept input. (Of course, I am talking substantive editorial improvements here: issues that boil down to OOXML should be ODF waste everyone's time, it is the wrong forum.)
These are modest but solid achievements: that is the way progress is, between revolutions.
Disillusionment: libraries not lawsSo what happens with OOXML now that it is a standard? Some opponents of OOXML felt it should not be standardized because standardization would not add any value to it; others felt it should not be standardized because by some unspecified and rather mystical force people would be forced to use OOXML if it were an ISO standard (a panic or successful FUD that has quite long staying power): I don't see that either is true. Some people have felt that ISO brand has been diminished by the standardization process.
But a precondition of dis-illusionment is having an illusion in the first place: JTC1 Information Technology standards must be considered a library of public technologies (progressively more open) which should only be transposed to National Standards by specific consideration of the National Body; furthermore, adoption as a National Standard in many (most?) nations does not imply any regulation that the technology must be adopted or preferred.
A standard on Information Technology is not a law. At most, standardization as a JTC1 technology may mean that in some cases procurement regulations or policy may require that OOXML and ODF should be considered. But their existence as standards with some overlap does not mean a choice cannot be made, any more than the existence of the prior ISO DSSSL standard means that W3C CSS or W3C XSL could not be used. (And surely it is hardly freakish or forced to consider important formats: what responsible procurement policy would not consider what to do about the native format for the market dominating applications? Even if the consideration resulted in a rejection of the standard spun off from Office in favour of the standard spun off from OpenOffice.)
There seems to have been a tremendous amount of speculative, alarmist guff written on this (and on the WTO TBT and Procurement requirements), with absolutely no evidence that the world operates or will operate in the way suggested.
Occasionally, some of the old FUD resurfaces: just this week I was sent an email claiming that the six thousand page specification is too complex and too inconsistent to implement. This email was not, apparently sent by a developer. OpenOffice 3.0 has an OOXML import filter. MS Office has an ODF import and export capability, Both will be improved: it will take a few release cycles of the various products to get up to speed: big deal.
But I have two other responses to this claim.
First, it treats "implementer" as meaning "implementer of an office suite". I have worked on several pieces of software that generate or accept OOXML. I would do the same for ODF if it came up: having the standards has made it relatively easy. It seems to me that there is a group who say "interchange" but actually mean "product substitution". So my experience as an implementer is quite positive, though many parts of the technology are a mess the standard often makes this clear, which is just the way things are when the technology predates the standard and has had a messy evolution: standardization gives you a standard sow's ear not a standard silk purse if you start with a sow's ear.
Second, as experience shows further flaws or omissions in IS29500, the standards process is there to fix them. The standards process is the only practical way to get collective national review and disclosure of these things, as far as I can see. But it only works by participation. Don't like OOXML? Then participate in ODF! Need more details in OOXML? Then participate.
Now I have stressed that JTC1 processes involves national review rather than public review. In some nations, participation is easier than others. But whether or not OOXML would benefit from more openness to the unwashed masses, competitors, consortia, and 'consultants with too much time on their hands' (a recent phrase from an anti-OOXML-er I enjoyed: apparently that should trump expertise!) —I think it would—it still needs systematic national review. They are not overlapping or mutually incompatible forms of openness. (By the way, OOXML is no different from ODF in this regard.)
[Update: I forgot to mention, congratulations to Rex Jaeschke and his co-workers on the difficult and hard work required, as well as to all the people who participated at ECMA and ISO, pro or con, for making a much-improved standard.]