Independent study advises IT planners to go OOXML | All about Microsoft | ZDNet.com

Sun, 20 Jan 2008 23:52:43 -0000

Highlights and Sticky Notes:

“ODF represents laudable design and standards work. It’s a clean and useful design, but it’s appropriate mostly for relatively unusual scenarios in which full Microsoft Office file format fidelity isn’t a requirement. Overall, ODF addresses only a subset of what most organizations do with productivity applications today.”

The report continues:

“ODF is insufficient for complex real-world enterprise requirements, and it is indirectly controlled by Sun Microsystems, despite also being an ISO standard. It’s possible that IBM, Novell, and other vendors may be able to put ODF on a more customer-oriented trajectory in the future and more completely integrate it with the W3C content model, but for now ODF should be seen as more of an anti-Microsoft political statement than an objective technology selection.”

Mary Jo takes on the recently released Burton Group Report comparing OOXML and ODF. Peter O'Kelly, one of the Burton Group authors, once famously said, "ODF is a great format if you live in an alternative universe where MSOffice doesn't exist!"

This observation speaks to the core problem facing ODF and those who seek to implement the ODF standard: ODF was not designed for the conversion of MSOffice documents. Nor was ODF designed to work with MSOffice applications.

Another way of saying this is to state that ODF was not designed to be interoperable with MSOffice documents, applications and bound processes. The truth is that ODF was designed for OpenOffice/StarOffice. It is an application specific format.

Both OOXML and ODF do a good job of separating content from presentation (style). The problem is that the presentation - layout layers of both ODF and OOXML remains bound to specific applications producing it. While the content layers are entirely portable and can be exchanged without information loss, the presentation layers can not.

Microsoft makes no bones about the application specific design and purpose of OOXML. It's stated right in the Ecma 376 charter that OOXML was designed to be compatible with MSOffice and the billions of binary documents in MSOffice specific binary formats. The situation however is much more confusing with ODF.

ODF is often promoted as being application, platform and vendor independent. After five years of development though, the OASIS ODF TC has been unable to strip ODF of it's OpenOffice/StarOffice specific aspects. ODF 1.0 - ISO 26300 had three areas that were under specified; meaning these areas were described in syntax only, and lacked the full semantics demanded by interoperable implementations. Only OpenOffice and StarOffice code base applications are able to exchange documents with an acceptable fidelity.

The three under specified areas of ODF are: Lists (numbered), Formulas, and Layout - Presentation (styles).

ODF v 1.2 will deal with the formula problem, but this version is still in committee - perhaps years away from ISO approval. The List model in ODF 1.2 further aggravates the existing interop problems. And the presentation-layout problem is not dealt with at all. Meaning, we can expect the ODF Interop problems to continue far into the future.

There is a solution, but not what people think.

Most observers think that it's possible to harmonize ODF and OOXML. This is wishful thinking. Since both ODF and OOXML are application bound at the presentation layer, the only way to harmonize them would be to harmonize the applications themselves. Meaning; alter how the applications implement basic document structures such as lists, tables, sections, fields and page dynamics so that the implementation models are similar. This would involve serious compromise of what each application provider considers to be innovative feature sets.

Efforts to harmonize at the application layer will not work. The vendors, Sun and Microsoft, are unlikely to compromise on their innovative differentials. And there is no hope of changing the application specific formats unless and until the application providers consent.

The solution that will work is that of relying on converters. While everyone wants MSOffice to implement ODF, this is structurally impossible unless a subset of ODF is designed for this purpose. And the OASIS ODF TC has already rejected six different subset proposals designed for compatibility with MSOffice and the conversion of billions of MS binary documents.

It's also impossible to convert from one application specific format into another without significant information loss. Maybe if Microsoft and Sun were to completely specify the presentation - layout layers this problem could be lessened. But that's unlikely to happen.

So what to do?

Convert to a generic format designed for universal interoperability!

The W3C's CDF was designed for universal interop. It is totally application independent, building on combining basic document structures within the XHTML - CSS - XForms - SVG framework. CSS in particular is an extremely portable presentation layer!

Given that the large application vendors are unlikely to compromise, the W3C's CDF may be the only solution possible. The idea being to convert MSOffice documents (binary and OOXML) to CDF, and, similarly convert OpenOffice/StarOffice ODF documents to that same CDF profile.

At this higher level of Web ready CDF, there is universal interoperability. But the solution does put incredible pressure on the conversion layers.

This approach looks very similar to the SOA model where XML connectors are routinely used to wire together legacy systems. A common XML schema is used as the conversion layer connecting many black box information systems, with each connector having to be written and implemented. From the common schema, the legacy systems can be wired into emerging Web information systems, creating a fairly good information flow. Interoperability between systems might not be perfect (it depends on the quality of the individual converters – connectors), but it is usually far beyond the zero interop of previous generations!

What i'm suggesting is that document interoperability can be achieved following a similar route to that of SOA. The legacy applications can be wired together using an advanced conversion layer connecting the applications to a common XML configuration. The W3C's CDF has the flexibility and reach to capture the richness of our desktop productivity legacy. The SOA approach allows us to continue to leverage that desktop application value without having to rip out and replace. Which is costly and disruptive to existing business processes.

~ge~
posted by garyedwards

Tags: burtongorup cdf css garyedwards maryjo odf okelly ooxml w3c xhtml

Posted by: garyedwards

Does ODF 1.2 Metadata Solve the Interop Problem? - Microsoft starts rolling out more OOXML translators |

Tue, 11 Dec 2007 23:17:07 -0000

Comments:

A Second response to Mary Jo's, “Microsoft starts rolling out more OOXML translators” is also posted here. The title is "Standardization by Corporation". Shish-Ka-Bob makes the assertion the ODF 1.2 metadata model will enable lossless two way conversion between MSOffice and ODF. While it's true that that intent was a key component of the original July of 2006 Metadata Requirements, the proposal was eventually stripped from the final submission made in April of 2007. I try to explain to Shish how that came about. The second post here, "Standardization by Corporation", is a follow on to statements made to Shish. The statements have to do with the events at ISO, and what i think will eventually happen. IMHO, ISO will follow either the AFNOR or Brittish proposals to merge ODF and OOXML. To do this they will remove entirely the coproarate vendor influence of Ecma and OASIS, and perfect the merger entirely at ISO. My post just happened to coincide with ISO Governor Mark Bryan's "Standardization by Corporations" letter. 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~ posted by garyedwards

Highlights and Sticky Notes:

Sorry Shish, you're wrong about ODF 1.2

Try ODF 1.5 or ODF 2.0, maybe.

The metadata requirements for ODF 1.2 actually did include two way lossless translation capability. Unfortunately these features did not survive the final cut, and were not included in the April 2007 submission.

You might also want to check the February 23, 2007 metadata proposal from Florian Reuter. That also would have delivered the goods and perhaps put ODF that grand convergence category of usefulness across desktops, servers, devices and web systems currently the exclusive domains of MS-OOXML and CDF+. Florian had devised a means of using metadata to describe the presentation aspects of content and structural objects. Very revolutionary. And based on the simple notion that bold, font, margins etc. are simply metadata about content and style objects.

Where the train came off the track had to do with the concept of an XML ID means of linking metadata to content. Not that there was anything wrong with this mechanism. It's actually quite clever. What went wrong was that Sun insisted that only those elements approved and supported by OpenOffice would be allowed to make use of XML ID metadata. For independent developers, this is a serious constraint.

Because of this constraint, the metatdata sub committee started off with six elements supported by OOo that metadata could be appied to. IBM then came in and asked for eleven more elements having to do with charts and graphs. The OpenOffice crew decided they could support this, so in they went. Then an interesting question was posed, "How are independent developers supposed to submit elements for metadata consideration?"

Tags: afnor cdf iso maryjo merger metadata odf ooxml opendocument talkback zdnet

Posted by: garyedwards

OpenDocument's feed | Diigo Group

Independent study advises IT planners to go OOXML | All about Microsoft | ZDNet.com

Does ODF 1.2 Metadata Solve the Interop Problem? - Microsoft starts rolling out more OOXML translators |