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~

This quote from Chalres Schultz is ridiculous. Because Novell is not allowed to commit code to OpenOffice, they must maintain a separate code base of extensions and improvements. With each build of OpenOffice, Novell must reintegrate their changes into the code base, making for a managerial nightmare.

When Novell does have improvements that Sun wants though, there is no end to the hoops of fire the Sun developers will jump through to get it. The Field Enhancement routine written by Novell's Florian Router is one of those improvements that Sun had to have. Sun even went so far as to arguing for changes in the way ODF implements fields to accomodate the Novell improvements!

It's important to note however that Sun did not support the ODF Field Enhancements UNTIL Novell agreed to donate Florian's code to OpenOffice!!!!!! Proving conclusively what i have been arguing for years: Sun does not allow for any changes to ODF unless and until those changes can be implemented by OpenOffice.

The ODF Field Enhancements needed by Florian's fix to OpenOffice were originally proposed on July 12th, 2006, when Florian was the CTO of the OpenDocument Foundation. These changes to the way ODF implements fields were needed by the da Vinci plug-in as part of our efforts to save ODF in Massachusetts.

so here we have a rather direct example of Sun refusing improvements to ODF when needed by another application (da Vinci), but supporting those exact same changes when it is OpenOffice that can be improved!!!

The arguments that the OpenOffice.org Community isn't open also apply to the OASIS ODF TC work!!!!!!

Good catch by Eric!

This link is to the infamous Sun statement of support for MS OOXML issued by Jon Bosak when ISO DIS 2900 was voted on by the US delegation to ISO.

The statement is important because it directly references the core issue: MS OOXML was written for MSOffice and the billions of binary docuemnts bound to that application suite. ODF on the other hand was written to OpenOffice.

Because ODF was not designed for the conversion of those billions of MSOffice documents, conversion is next to impossible. The implementation of ODF in MSOffice is next to impossible. The loss of information, especially the presentation-layout information, is so severe as to be intolerable in the real world.

This leaves the real world, where MSOffice dominates over 550 million desktops, unable to implement ODF. In light of this real world problem, Sun's Bosak urges support for MS OOXML as an ISO standard!!!

So we have this situation at OASIS ODF where Sun is in control of both ODF and OpenOffice, refusing in all cases to compromise the linkage or accomodate the much needed interoperability enhancemnts seeking to improve the conversion of billions of documents to ODF. And publicly supporting MS OOXML as the only pragmatic alternative to the situation Sun is responsible for!

This was a day long event demonstrating for all the world to see that there is no such thing as ODF interoperability. The exchange of documents between OpenOffice 2.0, KOffice and Lotus Symphony is pathetic.

The results of the day long event were so discouraging that Rob Weir took to threatening developers who attended in his efforts to keep a lid on it. I think this is called damage control :). From what i hear, it was a very long day for Rob. but that's no excuse for his threatening anyone who might publicly talk about these horrific interop problems. The public expects these problems to be fixed. But how can they be fixed if the issues can't be discussed publicly?

Lotus Symphony is based on the OpenOffice 1.1.4 code base that IBM ripped off back when OpenOffice was under dual license - SSSL and LGPL.

I don't agree with this statement from Microsoft's Oliver Bell. As someone who served on the OASIS ODF Technical Committee from it's inception in November of 2002 through the next five years, i have to disagree.

It's not that Microsoft wasn't welcome. They were. It's that the "welcome" came with some serious strings. Fo rMicrosoft to join OASIS would have meant strolling into the camp of their most erstwhile and determined competitors, and having to ammend an existing standard to accomodate the implementation needs of MSOffice.

There is simply no way for the layout differences between OpenOffice and MSOffice to be negotiated short of putting both methodologies into the spec. Meaning, the spec would provide two ways of implementing lists, tables, fields, sections and page dynamics.

A true welcome would have been for ODF to have been written to accomodate these diferences. Rather than writing ODF to meet the implementation model used by OepnOffice, it would have been infinitely better to wrtite ODF as a totally application independent file format using generic docuemnt structures tha tcould be adapted by any application.

It turns out that this is exactly the way the W3C goes about the business of writing their fiel format specifications (HTML, XHTML, CSS, XFORMS, and CDF). The results are highly interoperable formats that any applciation can implement.

You can harmonize an application specific format with a generic, applicaiton independent format. But you can't harmonize two application specific formats!!!!

The easy way to solve the document exchange problem is to leave the legacy applications alone, and work on the conversion of OOXML and ODF docuemnts to a single, application independent generic format. The best candidate for this role is that of the W3C's CDF.

CDF is a desription of how to combine existing W3C format standards into a single container. It is meant to succeed HTML on the Web, but has been designed as a universal file format.

The most exciting combination is that of XHTML 2.0 and CSS in that it is capable of handling the complete range of desktop productivity office suite documents. Even though it's slightly outside the W3C reach, the most popular CDF compound is that of XHTML, CSS and JavaScript. A combination otherwise known as "AJAX".