Rob

Some pertinent quotes from Microsoft’s Brian Jones, thematic quotes made over a sustained period of time:

• “The Open XML formats were designed to be 100% backward compatible with the existing set of Office binary formats, and that was really a goal that we can’t compromise on.”
• “It needs to be 100% full fidelity”
• “[F]rom our point of view, in order to use an XML format as the *default* format for Office it needs to be 100% compatible”
• “We need to make sure that the format is documented 100% and there are no barrier to interoperability”
• “This format is 100% compatible with the existing base of Microsoft Office documents, so nobody will need to worry about losing features”

Get the idea?

Now these quotes were all made before OOXML was completed. I understand engineering and deadlines and such, and that things don’t always all get done as planned. But I would like to know, now that we have 1.5 OOXML “final draft”, and Office 2007 has released to shipping, is it indeed indeed indeed 100% backwards compatible.

Two simple questions. I’m hoping Microsoft or Ecma can give a straightforward and unequivocal answer:

1) Is the Office Open XML specification (1.5 “final draft”) 100% compatible with all legacy Microsoft Office documents, meaning that a 3rd party, using solely information in this specification (and publicly available open standards), can create a utility on a non-Windows platform, say Linux, to convert any legacy Office document into OOXML without loss of data, function or appearance?

2) Does the OOXML specification (1.5 “final draft”) document the format sufficiently for someone to create a 100% compatible editor (spreadsheet, word processor, presentation) implementation on a non-Windows platform, say Linux? By 100% compatible I mean that it can load and interpret and display all OOXML documents without loss of data, function or appearance?

I note that everything we’ve heard up to now merely says that OOXML was designed to be 100% compatible. But I’d like to hear whether it in fact succeeded at doing these things. That’s the important question, right? We can talk intent all we want, but the results are what counts.

I believe that the criterion should be whether a 3rd party can create a conversion tool and editor based on the documented format. That fact that Office itself may do a conversion is not proof of anything. They could submit a specification both incomplete and erroneous but still do a good conversion job in Office based on private information. The proof of sufficiency for the specification only comes with independent 3rd party implementations.

These are simple questions. I’m hoping for a simple answer.

I refer you to Ben Langhinrichs at Genii Software with his post on “Self deprecating standards”.

After you’ve read that, then I hope you’ll return back here for some additional thoughts.

From what Ben writes, it seems that one source of OOXML’s length and complexity is that it had grandfathered in all sorts of special cases and exceptions for older versions of Office. So an implementor not only must worry about how Office 2007 does footnote placement, but also needs to worry about how Word 6 and Word 95 did it differently. Many other examples in his post. (Ben, you should take a look at the VML section — that entire markup is deprecated in the spec. )

We call this “crud”, the accumulated debris from old implementations, old platforms, old formats, old mistakes. Don’t get me wrong. As a forensic exercise in documenting the byzantine complexity of this arcane format the draft OOXML specification is a considerable achievement. The 6,000 pages testify to the industry of its authors as well as the thanklessness of their task.

But we need to keep in mind that there is a difference between a specification and a standard. A specification tells the plain facts of what a particular technology does without comment as to whether it is good or bad. I could drop a box of toothpicks on my desk and write up a detailed specification on how they landed. An open standard, on the other hand, goes beyond mere specification, and promotes a preferred way of achieving cross-vendor and cross-application interoperability. Ideally a standard says, “This specification is good, we thought of the wider needs of the market, including other vendors and the consumer, and if we all implement this technically elegant specification then we all win.”

However one thinks of the OOXML specification, it lacks the quality, the consideration and the perspective of an open standard. It was doomed from day 1, when its charter limited TC45 to not making any changes that would be incompatible with Microsoft’s existing proprietary binary formats. Think of it this way — The binary formats were certainly never designed to be a standard, right? They were developed in-house at Microsoft, kept from public scrutiny for 15 years, never brought before a standards organization, licensed on terms that prevented competition with Office, etc. Now, 15 years later they take the accumulated crud from 15 years of a proprietary binary format, convert it into XML and expect to call that an “open standard”?

From an architectural and design perspective this is all ass-backwards. You can build complexity on top of simplicity, but you can’t easily build simplicity on top of complexity. The recommended approach when designing a standard-aspiring document format is to survey the range of functionality in existing and anticipated implementations, map out the intersection of this complexity and then generalize it. The generalization of complexity often leads to simplification. A good example is the art page borders, where the OOXML specification enumerates hundreds of specific images that can be used in page borders, an approach which is at once limiting and complex. The generalization of having the document include the clipart would both simplify the specification as well as increase its functionality. Instead of this approach, Microsoft has squandered their opportunity to improve document-centric computing and interoperability and instead produced 6,000 pages of indigestible complexity, an approach that cuts off alternate implementations and props up their monopoly.

It is time to move on.