Group Bookmarks tagged harmonization
You are here: Diigo Home > Groups > OpenDocument > Bookmarks > Group Bookmarks tagged harmonization
This very funny satire builds on some harsh realities. The ODF chickens have come home to roost, and it isn't pretty. Very funny, yes. But not pretty for those who continue to believe that somehow ODF is a standard worthy of their support. The flip side of the coin is that using the same critieria of interoperability, OOXML is worthless. The sad truth is that both ODF and OOXML are applicaiton specific formats that will continue to defy and defeat all efforts at interoperability. Inparticular, it's the presentation layers of ODF and OOXML that remain bound to the layout engines and feature sets of their originating applications. Just as the presentation layers defy interoperability, they will also defeat harmonization. The only way to harmonize two application specific formats is to harmonize the originating applications. And Microsoft, Sun and IBM are not about to do that. The links in this satire are stunning!!! They shout loudly as to how Microsoft is going to respond to the ECIS anti trust allegations. So when you stop laughing, make certain you track down the links and read through the various OASIS ODF archive threads. IBM and Sun had their chance to fix ODF interoperability. Now it may be too late.
more from robweird.wordpress.com
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~
more from www.oreillynet.com
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: 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~
more from blogs.msdn.com
Gary Edwards (332)
mazyar hedayat (3)
marbux (1)