The summary statement glosses over the value of a highly structured portable XML document. A value that goes far beyond the strict separation of content and presentation. The portable document model is the essential means by which information is exchanged over the Web. It is the key to Web interop.

Up till now, Web docuemnts have been very limited. With the advent of XHTML-2, CSS-3, SVG, XForms and CDF (Compound Document Framework for putting these pieces together), the W3C has provisioned the Web with the means of publishing and exchanging highly interactive but very complex docuemnts. The Web documents of the future will be every bit as complex as the publishing industry needs.

This transition is accomplished by a very clever conversion component included in the MSOffice SDK. MS Developers can easily convert OOXML documents to Web ready XAML documents, adn back again, without loss of presentation fidelity, or data. No matter what the complexity!

The problem here is that while MSOffice-OOXML is now an ISO/IEC International Standard, XAML "fixed/flow" is a proprietary format useful only to the IE-8 browser, the MS Web Stack (Exchange, SharePoint, MS SQL, and Windows Server), and the emerging MS Cloud.

Apache, J2EE, Mozilla Firefox, Adobe and Open Source Servers in general will not be able to render these complex, business process rich, office suite documents. MSOffice-OOXML itself is far to complicated and filled with MS application-platform-vendor specific dependencies to be usefully converted to Open Web XHTML-CSS, ePUB or CDF.

XAML itself is only the tip of the iceberg. The Microsoft Web Stack also implements Silverlight, Smart Tags and other WPF - .NET technologies not available as open standards. Silverlight is a proprietary alternative to SVG and Flash technologies. Smart Tags and the LINQ meta search mechanism are alternatives to RDF, RDFa and SPARQL. And of course, XAML "fixed/flow" is a proprietary alternative to advanced XHTML-CSS, CDF, iPAPER, FlashPaper and PDF.

Web formats are important. This survey sadly only begins to scrape the surface of the interoperability problems the future of the Open Web faces. ISO approval of MSOffice-OOXML is going to initiate a great transition of legacy client/server business process systems to a new model of highly efficient, barrier free and cloud ready client/ Web-Stack /server systems.

Hope this helps,

~ge~

And here i was betting that the blueprints to the secret binaries would be released the weekend before the September 2nd, 2007 ISO vote on OOXML! Looks like Microsoft saved the move for when they really had to use it; jus tweeks before the February ISO Ballot Resolution Meetings set to resolve the Sept 2nd issues.

The truth is that years of reverse engineering have depleted the value of keeping the binary blueprints secret. It's true that interoperability with MSOffice in the past was near entirely dependent on understanding the secret binaries. Today however, with the rapid emergence of the Exchange/SharePoint juggernaught, interop with MSOffice is no longer the core issue. Now we have to compete with E/S, and it is the E/S interfaces, protocols and document API's and dependencies tha tmust be reverse engineered.

The E/S juggernaught is now surging to 70% or more of the market. These near monopoly levels of market penetration is game changing. One must reverse engineer or license the .NET libraries to crack the interop problem. And this time it's not just MSOffice. Today one must crack into the MS Stack whose core is tha tof MSOffice <> E/S.

So why not release the secret binary blueprints? If that's the cost of getting the application, platform and vendor specific OOXML through ISO, then it's a small price to pay for your own international standard.

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~