Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!

And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.

Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.

For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.

Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!

So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!

This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.

It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this route. The Sun - ODF covenant not to sue specifically exempts eXtensions to ODF not involving Sun! Meaning, if the interoperable subset of ODF was designed and implemented without Sun-OASIS participation and approval, the covenant not to sue does not apply. Developers beware! You cannot safely eXtend ODF without Sun's permission.

Here is the relevant text from Sun's covenant: "Sun irrevocably covenants that, subject solely to the reciprocity requirement described below, it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates to the point of incurring an obligation, as defined by the rules of OASIS, to grant (or commit to grant) patent licenses or make equivalent non-assertion covenants."

The obscurity of intent is masked in clever legalese. Which means, bring your legal team if you want to eXtend ODF, and prepare to argue.

My point is that this covenant could have been written clear and direct to say that Sun will not sue anyone for any reason related to ODF. But they didn't do that.

People will of course wonder why ODF is so bad that it might a as well be ZERO interop? The answer to this question is complicated, but a good place to start is to observe that, just as OOXML is an XML encoded dump of MSOffice in-memory-binary-representation, ODF is an XML encoded dump of OpenOffice/StarOffice in-memory-binary-representation.

The interop problem truly kicks in at the level of specifying this encoding. The Ecma and OASIS technical committees are responsible for fully specifying the OOXML and ODF. This means a complete syntax and semantic description needed to properly implement the specs. ODF and OOXML share one very big fault; the presentation-layout layer (or styles) is not fully specified! We have the syntax but not the semantics describing how layout works. This is particularly problematic in that both ODF and OOXML are application specific dumps. While they each do a good job separating content from presentation, neither fully specifies the presentation layer. Nor is the presentation layer portable in the sense that a CDF XHTML + CSS separation is portable.

And it is the presentation layer that binds the formats to their originating applications. MSOffice has one way of implementing basic document structures like lists, fields, tables, sections and page dynamics, and, OpenOffice has another. That these application differences are embodied in the formats creates an enormous interoperability problem. Applications can exchange content, but break when trying to interpret another applications presentation-layout layer. Especially when that presentation layer is under specified!

There were three aspects of ODF 1.0 that were under specified: numbered lists, formulas, and styles (presentation-layout). ODF 1.2 attempts to fix the formula problem, but does nothing for styles. The numbered lists "interop" problem was not fixed, but exacerbated.

So even though the binary blueprints were released two years ago to Sun and IBM, we have yet to see any improvement in conversion fidelity able to crack the lock MSOffice workgroup-workflow business processes have in the marketplace. Writing a subset of ODF enabling us to achieve that high fidelity conversion has a legal cloud hanging over the process. And all of these concerns are shadowed by the fact that neither OOXML or ODF have fully specified their presentation layers!

No wonder the W3C's formats are attracting so much attention.

~ge~

Will ISO follow either the AFNOR or Brittish proposals to merge ODF and OOXML? I think so. If they continue on their current path of big vendor sponsored document wars, ISO will beocme irrelevant. Sooner or later the ISO National Bodies must take back the standards process from corporate corruption and influence.

One thing is clear. Neither Microsoft or IBM is about to compromise. IBM has had many chances to improve ODF's interoperability with Microsoft Office and the Office documents, but has been steadfast in their stubborn refusal to concede an inch.

Microsoft hides behind their legacy installed base of over 550 million MSOffice desktops. There simply isn't a pragmatic or cost effective way of transitioning the installed base to ODF without either seriously re writing and replacing those applications, or, changing ODF to be compatible.

The marketplace is clear on what they intend on doing. Pragmatism will rule. Productivity trumps standards initiatives whenever they are out of sink.

In the face of this clear marketplace intent, one would think IBM might compromise on ODF. No way! They are intent on using ODF to force a market wide rip out and replace of MSOffice.

Most people assume that there are two opposing groups at war here; the Microsoft OOXML group vs. the IBM ODF group. This isn't an accurate view at all. There is a third, middle group of developers working the treacherous space of conversion - the no man'sland between OOXML MSOffice and ODF OpenOffice.

The conversion group know the problems involved, and are actually trying to dliver marketplace facing solutions. The vendors of course are in this war to the bitter end, and could care less about the damage they cause to end users.

It's also true that the conversion group seeks to bridge desktop productivity into the larger, highly interoeprable web platform.

It's also possible that ISO will chose to merge ODF and OOXML, as proposed by the French AFNOR plan as well as by the British. To do this they must first remove entirely the coproarate vendor influence of Ecma and OASIS, and perfect the merger entirely at ISO. The big vendors will of course fully oppose this approach.

My post just happened to coincide with ISO Governor Mark Bryan's "Standardization by Corporations" letter where he expresses a derpressing but nevertheless very true concern.

In fact, the OpenDocument Foundation was created specifically to address our concerns about the undue influence big application vendors were exerting on ODF following the April 30th, 2005 approval of ODF 1.0 (which went on to become ISO 26300).

~ge~