A commentator (and watcher) of my blog, says phunnily that people are “running out of technical arguments since the successful ballot resolution meeting in Geneva …”. Humbug! Are there are no more technical arguments against ooxml? How so? I will leave it as an exercise to that watcher to refute all those technical issues still pending that have been well documented in many places – so get on with it. We have till 5pm CET Saturday march 29th 2008 to put a closure to this waste of time.

He further says:

“Withdraw OpenXML from FastTrack and submit it under a “normal” process.
FastTrack is a “normal” process, it was developed by JTC1 to provide a mechanism for standards coming from industry to make their way through the ISO process. At a very high level FastTrack simply starts part way through the conventional ISO process, there is no need to convene a committee to develop a specification from scratch when a Liaison-A organization such as Ecma already has a draft document that is ready to be reviewed.”

Which part of “fast track” does he not understand? It is called that because it is not the normal process. The normal process has rigour. Most fast track submissions have a significant amount of rigour in the submitting bodies especially when they are PAS submitters like OASIS and the Free Standards Group. Ecma aka “standards@internet speed” has poor quality and processes and hence we see all the issues in ooxml. Which part of that does he not understand?

He also says:
“How can we approve OpenXML when we have not seen the final specification.
The final text of the specification is a combination of the draft international standard (DIS) that was published prior to the BRM combined with the resolutions that were passed by the member countries present at that meeting. There can be no last minute edits, surprises or other changes beyond those two documents.

I am told that during the last hour of the last day of the BRM the ITTF stood up and clarified the ISO/IEC position on this issue as it relates to a final draft of the specification, stating that the editor has an obligation to deliver a final version of the document no later than thirty days after ratification of the standard.”

Humbug. Why would anyone wait till the “last hour of the last day” to be told that the final draft will only be available 30 days after the vote? If that is the case, then I vote NO to ooxml. I am answerable and accountable to the standards process in Singapore and I will not agree on something that I cannot see. Sp, poster, could you send me a couple of signed blank cheques? I would like to write some number on it and send it to any charity you name. They will be most thankful of the donor.

Next point:
“I don’t have all the IPR and patent rights to implement OpenXML. The Microsoft Open Specification Promise is pretty clear in that it is a direct grant of rights far all patents needed to work with OpenXML made to every individual on the planet, irrevocably and in perpetuity.”

If someone does work with ooxml of the current version, your OSP only covers that version. If there is a new version, as it is now, your OSP does not cover that new version. This was confirmed by your colleague when it was asked at a presentation to the ITSC. Why don’t you go check with him then?

And a final MS FUD from the poster:
“There can only be one document format standard.
This one implies that standardization is a little like the movie Highlander, somewhere there is an implied winner and a loser. In reality this has never been the case. Standards frequently feed of other standards, as Patrick Durusau (ODF Editor) recently pointed out.

The argument also dismisses the state of the industry in general, as the CEO of I.R.I.S recently pointed out to Stephen McGibbon, there are already a plethora of document formats serving a range of complex use cases. The I.R.I.S OCR software support 75 of them today, so the question is really around support for a 76th format, not a 2nd format.”

I think Patrick is terribly confused – don’t take my word for it – check his deputy’s blog. I would agree with anyone that more standards the merrier. But the key differentiating factor here is “fully published and open standards”. PNG, JPEG, MPEG, BMP, SVG, GIF, MP3, OGG are all standards in similar areas and I will say that it is good. Each standard has its merit. They are fully published and fully defined. ooxml, on the other hand, is NOT. It could be if we disapprove it, send it back to ECMA, get them to clean it up and then come back – even in another fast track – and I will support ooxml if it meets those requirements. Stop beating around the bush about ooxml in it’s current form being good.