Brian Jones responds to Rob Weir's very strange demand that he be put in charge of any harmonization effort involving ODF and OOXML.
In his response, Brian points to the Ecma official statement in support of harmonization provided in February of 2007. The harmonization response was directed at ISO National Body members objecting to the proposed fast tracking of OOXML.
In late February -early March of 2007, the EU held an "interoeprability Workshop" in Berlin, Germany.The session was attended by IBM, Sun and Microsoft, as well as Ecma and OASIS.
The EU took a very hard line position on "harmonization", embracing a position put forward by the French ISO NB group known as AFNOR. The WorkShop was followed by the EU establishment of DIN Workgroup NIA-01-34, headed by the Fraunhoffer Fokus Institute.
The DIN WG sent out invites to all the major players, with Microsoft and Novell accepting the invitation to particpate in the harmonizatioon effort. IBM and Sun refused the invitation.
Recently DIN invited the OASIS ODF Technical Committee to join the harmonization effort. The OASIS TC responded by asking Novell developer (and DIN participant) Florian Reuter to act as liaison to DIN. ODF grand puba Rob Weir himself put forward this request.
Here's the thread:
http://www.oasis-open.org/archives/office/200801/msg00040.html
Now it looks like the grand puba is backtracking! Rob Weir wants to put himself in charge of harmonization. And we all know where that would lead.
Harmonization will be difficult. It might even be impossible. As indicated by the Ecma statement Brian copiies in his post.
The dynamics of harmonization are fairly simple to understand; you can't harmonize two application specific formats without also harmonizing the applications. This problem is further complicated by the fact that the presentation layers (styles) of both ODF and OOXML are woefully underspecified. While each format does a great job separating content from presentation, it is the presentation layers of each that remain stubbornly application specific.
Neither presentation layers are in anyway as portable, application independent and interoperable as the widely used CSS, especially when considering the advances proposed with CSS 3.0 or implementations using CDF WiCD profiles.
Since there are over 550 million MSOffice desktops, many of which are locked into set business processes and other workgroup-workflow related routines critical to day to day operations, changing MSOffice within the installed base is improbable. The cost of such a disruption would be prohibitive. The demands of legacy business processes will dictate with an unbending pragmatism that the ODF community will have to be the one to compromise.
That said, an ODF compromise is actually rather easy. This can be done by an ODF subset focused on a high level of compatibility with the legacy binary documents and interop with existing MSOffice processes.
To get there we need two things. On the one hand we need Microsoft to fully specify both the syntax and the semantics of their binary and xml formats. And on the other, we need the ODF vendors to fully specify all application specific settings, provide an interoperability framework with real compliance – conformance demands, and, enable generic elements upon which the compatibility subset can be built. ODF needs to be fully disconnected from OpenOffice, fully specified, and, OpenOffice needs to embrace interoperability as the first principle, with innovation constrained within the “interop first” development box. (Today, innovation trumps interop at both OASIS ODF and OpenOffice).
The other approach to interoperability is the one first advocated by the Foundation. Rather than trying to harmonize or map two application specific formats, the easier route is to convert the applications specific formats to a generic, neutral, application-platform and vendor independent format that was designed for universal interoperability. Like the W3C's CDF :)
Once converted to CDF, end users will find excellent interoperability across the web platform. It's not the kind of vendor-specific-desktop-application to other vendor-specific-desktop-application interop users had hoped for. But the interop across the web platform is a very special value in and of itself.
Besides, once the vendor-specific-desktop-applications have perfected high fidelity lossless conversions to the neutral, web ready format, these connections will sink into the applications, unnoticed by users. The effect will that of a dynamic and interactive pdf independent of any particular application feature sets or structural implementation models.
~ge~
Gary Edwards (343)
marbux (24)
Jesper Lund Stocholm (9)
mazyar hedayat (4)