Brian Jones had just blogged that more compatibility settings in OOXML is going to be defined more properly. Along with the announcement about other changes, OOXML is finally making a start on the long (and bumpy and whining) road to become an acceptable international standard, rather than a proprietary and vaguely defined rubbish it was.
Now, bear with me. I am taking you on a detour here. My intention will of course be clearer later. Imagine you have a seat in your company’s committee defining Standard Operating Procedure (SOP) for others to follow when they perform a certain complicated task. Previously, the authors of the SOP submitted their near-to-final draft for comments in a meeting. In that meeting, the consensus was there are some recommendations that the authors should consider when writing the final draft. Today, you received the final draft. After flipping through the pages, you find that there are a lot of new material and significant rearrangement of presentation order. Now, let’s make the assumption that they are all for the good of the SOP. However, looking at your calendar you realize that there is insufficient time to properly review the changes before the next meeting? What should you do?
My recommendation? Ask for an extension immediately. Failing that, at the next meeting, you will have to consider seriously the option of rejecting the proposal. After all, a bad SOP is worse than no SOP at all, especially if the changes have Health and Safety implication. I hope you agree with me on this.
Back to topic. So far, nobody, with exception of National Body and ECMA members I suppose, seen the revised OOXML standard. However, from Brian Jone’s discussion, it is clear that there were significant changes. Some changes, such as adopting ISO Dates, requires careful scrutiny. The description of compatibility settings, as Jones described in the first linked blog posting will all need to be independently checked for accuracy and correctness.
By introducing these at such a late stage, there is a possibility that the required due-process is not possible for the changes proposed. National Bodies’ working committee will certainly do not have the time considering the fact that the next Ballot Resolution Meeting is about a month away. The alternative, not as good as the signal-to-noise ratio is high, is to open up the specification for everyone to see and hope that the virtue of “many eyes” will achieve the desire effect. So far, we have none.
That is alarming, if the changes is as substantial I think it is. Just on top of my mind, insertion of about 20% more material, in the form of description of the “compatibility settings”, some changes that really need close scrutiny, such as ISO date insertion and the reorganization of the already substandard writing. In effect, I think it qualifies as a new revision, not an update to existing draft.
ISO fast track process is intended to make the road to ISO standardization faster for ready, well-studied and well formulated standard defined elsewhere. It make sense that if another standard body had scrutinized the proposed standard already, ISO need not go through the process again.
In the case of OOXML, it is blatantly obvious that OOXML was no where ready when it was proposed to ISO. At the very least, the writing is bad and not something you expect to see at international standard body level.
These changes should not had happen at such a late stage. They should had been discussed in ECMA committee stage. I am not asking the ECMA committee to adopt all changes, but rather, if they reject these rather obvious omission, they have an explaination for it, made public together with the proposal the standard to ISO. The only conclusion that I can draw is that the ECMA committee, despite consisting of big names such as British Library and Apple, was sleepwalking.
We should, however, recognized that OOXML proposers had made significant move from their original position. We must give credits where credits are due. My recommendation, assuming my speculation turn out to be true, is to reject OOXML this time, but with the recommendation that ECMA address those issue carefully (or better, the creation of an ISO working committee to take over the work from ECMA) and resubmit it at a later date.