Like a vampire that refuses to die, OOXML's ISO-ification process continues. Or rather like a festering sore that continually oozes pus.

As of the end of February, the ballot resolution meeting concluded by recommending changes to the text of the draft text of ISO/IEC DIS29500. The participants seemed to feel that it was the best they could do in the limited amount of time they had available and under the rules that were adopted for the meeting. It might be fair to say that many would have been happier if they had more time to discuss proposed changes to resolve the issues that were raised throughout the process.

I would recommend taking a look at Andy Updegrove's ConsortiumInfo site for further information on this proposed standard. Tim Bray also has plenty of information about the BRM and OOXML. Mr. Bray also has information for those speculating on the outcome of the process.

Importantly, the SFLC has examined the legal aspects of Microsoft's OSP relative to OOXML and concludes that it is not advisable for FLOSS projects to implement the specification.

Sadly, Microsoft could have made the process decidedly less painful. I recall that when Ecma was first expanding the OOXML spec Microsoft delivered into the 6,000 page behemoth it became, that a multitude of comments were made in public fora as well as on sites like Groklaw, advising where their choices were mistaken. Once the spec was publicly presented as Ecma-376 and preparing for presentation to ISO, even more flaws were pointed out. Unfortunately, the Ecma mandate required them to remain compatible with what they were given, something that is still blocking improvements to the specification.

Regardless of the outcome of ISO-ification, the rancor could have been avoided. Open source and open standards advocates, along with end-user advocates and even competing companies would have been glad to have a specification that was developed in the open, designed to avoid dependencies on specific hardware or software environments, with international needs as well as handicapped-accessibility in mind, planned from the beginning to be free of all "IP" issues, friendly to all implementers, and designed with end-user concerns and archiving in mind. All would have contributed.

Why? Because there really isn't an "anything but Microsoft" crowd. There are those who support other products, technologies, and business models, but they are not necessarily hostile to Microsoft unless MSFT first earned their hostility.

Instead, we all want to see Microsoft held to the same standard of conduct that everyone else must follow. We desire to see level playing fields, where products compete on quality and features, rather than on which is more "compatible" with a monopolist's products. I know that I want to be able to exchange documents seamlessly with anyone, regardless of whether they use Microsoft Office, Sun StarOffice, Corel WordPerfect Office, or some clown's BozoOffice. If that goes against the interest of Microsoft in maintaining their monopoly status, I'm sorry.

This standard was too big and complex for a fast-track process to work. It needed to go through a full committee evaluation. This standard also points out some deep flaws with ISO and with voluntary standards in a world where compliance may be (and often is) mandatory. See ISO9000 in Europe for an example of this.

Since standards tend to become legal requirements, it is important that standards are openly developed, and include members of the public on their committees. They should be free of legal and "IP" restrictions for all time and in all versions, so that anyone can implement any part of the standard for any purpose in any application at any time without permission. Standards should be royalty-free, and should be implementable by those using any licensing or business model, including open source, freeware, shareware, careware, donationware, or the standard proprietary software ultra-restrictive EULA. In fact, I suggest that the reference implementation should always be open source.

As it stands now, I don't think OOXML is fit for ISO standardization, especially given the requirements highlighted just above. I would like to take this opportunity to request that Microsoft take a Mulligan and redo this specification. In the mean time, I'd also like to request that they fully-implement the latest version of ODF as a fully-equal format to OOXML and the old binary formats. Look at the flaws in the OSP and see how it can be "patched" to make OOXML acceptable to free / libre and open source software projects, now that you know the flaws are there. SFLC has shown the way, now it is up to you to walk in it.