Lotus Symphony is OpenOffice 1.1.4, which IBM took private while OpenOffice was dual licensed under SSSL-LGPL. In October of 2007, after the incredilbly disastrous ODF Interoperability WorkShop held at the OpenOffice Conference in Barcelona, Spain, IBM commissioned Sun to fix Lotus Symphony. This was done under the guise of IBM contributing to the OpenOffice source code.

One of the funny events at the ODF Interop Workshop was the line of Sun OOo/SO developers walking up to the Lotus Symphony demo station and popping the OOo 1.1.4 easter egg - then walking away.

KOffice has been a member of the OASIS ODF TC for five years now, and the interop between KOffice and OpenOffice might as well be zero. At some point in time people are going to have to start wondering why ODF interop is so bad - especially among contributing members of the OASIS ODF TC!

My own take is that ODF suffers from the same application specific problems that will forever doom OOXML. The presentation layers of each format are entirely reflective of the application specific idiosyncrasies, feature sets and layout engines unique to the originating applications.

There were three areas of ODF 1.0 - ISO 26300 that were woefully un specified: numbered lists, formulas and the presentation (styles) layer.

When Sun submitted what was then Open Office XML to OASIS, the specification was clearly an XML encoding of the OOo/SO binary dump. It was not the clean slate so many now claim it to have been. The clean up of the spec began with an effort to thoroughly document the different packages (content, styles, metadata, settings, manifest). Once fully documented, the idea was then to genericize any application specific findings. Sad to say, but five years have gone by and the presentation layer in particular has yet to be fully documented, let alone cleaned to the point of application independence.

As for OOXML? Forget it. They make no bones about the fact that OOXML’s entire reason for being is that it’s application, platform and vendor specific.

There was a point in time prior to the open sourcing of OpenOffice when Sun considered writing a browser for StarOffice. One of the browser requirements would have been (X)HTML - CSS 2.0 compliance. This led to an intense discussion as to whether or not OOo/SO could produce read-write (X)HTML - CSS 2.0 formats useful to the browser. The decision was that this work would require a total rewrite of the OOo/SO layout engine. So the browser project was dropped.

Think of the impact this decision has had. XML itself does not have a presentation layer descriptive. W3C materials suggest CSS, XSL or XSL-FO to fill that void. CSS in particular is perhaps the most portable and universally interoperable presentation layer in use today. This however would have been a difficult and costly choice for Sun.

Because of the legacy layout engine in OOo/SO, Sun choose a uniquely application specific presentation layer called “automatic-styles” when they moved to develop an XML format.

Having lived through the ODF process since it began in October of 2002, i would have to say that the right way of doing an XML interchange format would be to write a clean room spec based on generic document structures - and without application vendor participation. Generic elements might have cascading attributes that begin with basic “must have” metadata moving into ever more complex (and application specific) descriptives. This way an interoperability - interchange base can be used to service simple applications without compromising the rich, full featured needs of complex productivity environments.

This stuff isn’t easy. But if “interchange” is the purpose, then we can’t allow a handful of legacy application vendors dictate design. Once the basic spec is in place, invite the vendors to run test implementations with feedback comments.

Oh wait! That’s how the W3C designs formats. They follow without exception the first law of the Internet: Interoperability trumps everything, and is never compromised. Including demands for innovation. Including demands for application, platform and vendor specific needs.

~ge~