The vote on OOXML should be based not on business relationships but based only on the merits of the candidate at hand. So, we have accumulated some previous posts of interest:

Posts on OOXML technical deficiencies:

• Oops! Microsoft Admits OOXML is Flawed
• Monoculture Defines Bugs as Standards
• Even Microsoft Might Not Obey That Broken OOXML
• Why ODF and Why Not OOXML
• Technical Flaws in OOXML and Technical Flaws in ISO (When Subjected to Sheer Abuse)
• OOXML: A Broken Design or Broken by Design?
• It's a Technical Thing, and OOXML is a Total Mess
• OpenXML is Really Funny (But It's a Joke That Can Cost Lives)
• OOXML: Both a Patent Mess and a Technical Mess
• Microsoft's Excel Fails at Maths Again, New Warnings About OOXML Defects

There is another new one from Rob Weir.

In summary, we are concerned that the ST_Xstring type in OOXML opens us up to problems such as:

1. Introducing accessibility problems 2. Breaking unaware C/C++ XML parsers 3. Breaking XML databases 4. Breaking interoperability with other XML languages 5. Breaking application logic related to string searching, sorting, comparisons, etc. 6. Introducing errors that will be hard to detect and resolve

OOXML cannot be rushed. It's in an utterly poor state with far too many unaddressed problems. That is a fact. It would be irresponsible to have accepted such an immature specification.

No matter how many people and proxies (e.g. ECMA) Microsoft assigns to this, it cannot be done and it certainly cannot be fast-tracked. You can't get 9 women to deliver a baby in 1 month. ⬆