I view the spec as confusing, obtuse, error-ridden, x86-centric, incomplete, and redundant.  Microsoft sat on the board of ODF for _years_ without offering any help on the minor items ODF didn't provide that they wanted.  Now that governments start pressing for permanent standards on document storage, MS throws out this half-baked item and expects a reward for good behavior.  Maybe somebody on the board of directors at our company likes it, but the technical folks having to add more work are less than happy about this beast.

If they had to go with XML, couldn't they at least have allowed standard XML with attributes and the like instead of x86 specific, binary incompatible, past-version deprecating, standard-avoiding, crash on normal XML.. ... mess... that they have offered for consumption?  Oh.. but wait, I'm sure the BRM fixed that in the week given.  I'm sure the pretty version will show up any day now.

There can be no doubt that OOXML, as a standard, has severe flaws.   It is incomplete, platform specific, application specific, full of contradictions, fails to adhere to existing standards, untestable, and presents a moving target for any IT worker.  There is not an organization in existence, including Microsoft, that promises to actually implement the full standard.  Much of this is due to the fact the final version doesn't actually exist on paper yet, but a large fraction is also do to the patchwork nature of the product.

The reason governments and companies wanted a 'office apps' standard in the first place was to release an avalanche of data from aging applications.  OOXML shows every appearance of being created to prevent this escape, not enable it.   The immaturity of the standard means that it remains a gamble to see if older documents will remain readable or not.  The lack of testing means there is no way to determine what docs actually adhere to it or not.  The ignoring of existing standards guarantees compatibility problems.  All of these factors are handy for the owner of the biggest share of existing documents, as it forces users to continue to use only _their_ application or risk danger from every other quarter.

What is to be done?

ISO has in a sense put itself in an awkward position here by
already approving the rival OpenDocument
format as an ISO standard. This makes it harder to reject OOXML, and
at the same time makes it difficult to approve OOXML, since it
competes with an existing ISO standard. Generally, I'm unhappy with
how closely these two standards are tied to existing software. What I
would really have liked to see was for OpenDocument and OOXML both to
be dropped, and the two communities to sit down and work out a common
agreed format that is not tied to any existing software. The Chinese
UOF
format, for example, might have served as the starting point for
this. ODA has
also been suggested. Unfortunately, this requires a political will
that does not seem to be present, and so this seems unlikely for now.

'A diversion from the real end game – the taking of the internet'

garyedwards's Discussions

So here are some "Key Messages" from Microsoft's standards team circa 2003 (doing battle with the Australian parliament no doubt) [Emphasis added]:

• An open standard is a publicly available specification which details certain technical functionality that may be implemented in different products and services.  It is adopted in an open, consensus-based process and must satisfy other criteria for transparency, ease of access, and broad implementation as described below.



• Open standards exist to facilitate interoperability and data exchange across various products and services in a marketplace of multiple, competing implementations, while ensuring that certain minimum requirements are met.



• Other types of standards (e.g., “proprietary standards”) and market-based mechanisms exist and are currently used to facilitate interoperability.  However, open standards ensure the highest level of interoperability across the widest range of competing products and services.

We eventually found out that if any changes affected current implementations it would certainly be rejected. This seriously compromised any elegant solutions, and it forced us to be mindful of the "existing corpus of documents" in the wild. I personally don't believe that that should be our problem, but there was a large and vocal voting bloc which would oppose any changes to the spec which would 'break' Ecma 376.

This was why appeasing Ecma had to happen. Even though they rushed their Ecma International Standard, and Microsoft took the risk in shipping Microsoft Office 2007 last year, we now have to bear the burden of having to support its limitations. This also means that future maintenance changes would get harder and harder.

Lebech said Denmark considers OOXML an open standard, regardless whether it is approved by the ISO. "It would be impossible
for us to use only ISO standards if we want to fulfill the goal of creating interoperability in the government sector," he
said.

The Danish Parliament also mandated that public agencies consider the cost of using open formats. One of the main reasons
OOXML was included is because Denmark is heavily dependent on document management systems that are integrated with Microsoft's
Office products, Lebech said.

Denmark also found that requiring agencies to only use ODF would have been too expensive, mostly because of the cost of converting
documents into ODF, Lebech said.

"We wouldn't have been able to only support ODF," Lebech said. "It wouldn't have been cost neutral."

A Savage Journey …

IMHO, the key to Microsoft's OOXML strategy can be seen in the recently released MSOffice SDK. The SDK provides a component for the fluid conversion of OOXML to something called fixed/flow. The fixed part of this interesting conjunction is also known as XPS, which is designed as a proprietary alternative to PDF. The flow part is a fascinating and highly proprietary replacement for (X)HTML - CSS.

Reading further through the MSOffice SDK, one can't help but be amazed at the lack of W3C technologies; especially (X)HTML, CSS, XForms and SVG. What we have instead is an entangling cascade of stuff like OOXML, fixed/flow, silverlight, XAML, and WPF. And then there is that recent promise of other high volume API's probably delivered through future Exchange, SharePoint, and MS SQL Server SDK's.

So, at the end of the day, what are we looking at here? IMHO, Microsoft has figured out that the smart thing to do is leverage and extend their existing desktop monopoly into the next generation of cloud computing where the Internet platform rules.

To pull this off, they have a number of problems to overcome; not the least of which is that they need to catch a break on anti trust, and, get OOXML through ISO. And oh yeah, there's that little problem that Windows can't do cloud computing.