MS-OOXML supporter Rick Jellife discusses the ODF Alliance response to Ecma's proposed disposition of ISO NB comments on OOXML. The Allaince response has recieved quite a bit of ink, wtih waves of ODF jihadists pointing to it as incontroverible evidence that they are right. Rick provides a lengthy response, most of which presents the ODF jihadis with some difficult issues they must now explain.

More importantly though, RJ uncovers one of the more glaring examples proving that ODF is application specific to the core, and bound to OpenOffice. He points out that OpenOffice ODF could have chosen the W3C's highly portable and infinitely interoeprable CSS as the ODF presentation layer. This would have been a great reuse of existing standards. But that's not what happened!

Instead of the widely used CSS, OpenOffice chose an incredibly application specific presentation model with the unique innovation of "automatic-styles". And with this choice came years of problematic zero interop as application after application try to exchange ODF documents with little success.

Take for example KDE-KOffice. They've been a member of the OASIS ODF TC for near five years now, almost since the beginning. Yet it's impossible to exchange all but the most basic of documents with any of the OpenOffice derivaties (OpenOffice, StarOffice, Novell Office, and Lotus Symphony - OOo 1.1.4).

If after five years of active particpation and cooperative efforts, KOffice is unable to exchange ODF docuemnts with OpenOffice, how is it that somehow Microsoft Office would be able to implement ODF without similar zero interop results? Isn't the purpose of standardized formats that end users of different applications could effectively exchange documents?

The truth is that both ODF and OOXML are application specific formats. And you can't harmonize, merge, map, or translate between two application specific formats without also having harmonized the applications.

Fear not though. It is possible to convert an application specific format to a neutral, generic, application independent format. The W3C's family of (X)HTML formats qualify in this respect. In particular, (X)HTML-5 with CSS-3, with a CDF mix of XForms, SVG and SMiL where needed, can cover the full richness of legacy desktop productivity documents. And do so with the added advantage of being universally interoperable at this higher layer.

So the solution to ODF and OOXML interoeprability problems is not to merge or harmonize. The best approach is to convert to the universally interoperable formats provided by the W3C.

Still, one has to wonder. Why is it that first Sun with OpenOffice/StarOffice, and then the OASIS ODF TC, decided against the highly portable, incredibly interoperable CSS presentation layer in favor of an obscure, entirely application specific method unique to OpenOffice? A bad choice indeed.

~ge~

Tags: harmonization hypocrisy interop iso odf odf-alliance ooxml opendocument openxml on 02-06-2008 -Cached -About Shared by:Gary Edwards

more from www.oreillynet.com

The ever audacious and prevaricating lobbyist group known as the ODF Alliance has posted their critique of Ecma's (Microsoft's) proposed disposition of ISO comments rejecting OOXML. The critique's appeal to ignorance is breath-taking in scope. E.g., whilst slamming DIS-29500 on the subject of interoperability, the same document pushes for harmonization using the following argument:

"Harmonization starts from looking at where the two formats overlap – and there is a significant, perhaps 90 percent or more, area where OOXML and ODF do overlap – and expressing this functional overlap identically. This common functionality between ODF and OOXML would also include a common extensibility mechanism. The remaining 10 percent of the functionality, where these standards do not overlap, would represent the focus of the harmonization effort. That portion of it which represents a widespread need could be brought into the core of ODF. That remaining portion which only serves one vendor's needs, such as flags for deprecated legacy formatting options, could be represented using the common extensibility mechanism."

And precisely how do vendor-specific extensions aid interoperability, particularly when the proposed "harmonization" does not require profiles and an interoperability framework?

Tags: brm odf odf-alliance ooxml opendocument openxml on 01-30-2008 -Cached -About Shared by:Gary Edwards

more from www.odfalliance.org