Group items tagged

Marbux on metadata and the language of universal interoperability: Few people are aware of the raging debate that has pushed ODF to the edge. The OASIS ODF TC is split between those who support Universal Interoperability, and those who insist on continuing with limited ODF interoperability.

ODF (OpenDocument), formally known as Open Office XML, began it's standards life in the fall of 2002 when Sun submitted the OpenOffice file format to OASIS for consideration as a office suite XML fiel format standard. The work on ODF did not start off as a clean slate in that there were near 600 pages of application specific specification from day one of the standards work. The forces of universal interop have sought for years to separate ODF from the application specific features and implementation model of OpenOffice that began with those early specification volumes, and continues through the undue influence Sun continues to have over the ODF specification work.

Many mistakenly believed that submission of ODF to ISO and subsequent approval as an international standard would provide an effective separation, putting ODF on the track of a truly universal file format.

Marbux is one of those Universal Interop soldiers who has dug in his heels, cried to the heavens that enough is enough, and demanded the necessary changes to ODF interoperability language.

This post he recently submitted to the OASIS ODF Metadata SC is a devastating rebuttal to the arguments of those who support the status quo of limited interoperability.

In prior posts, marbux argues that ISO directives demand without compromise universal interoperability. This demand is also shared by the World Trade Organization directives regarding international trade laws and agreements. Here he brings those arguments together with the technical issues for achieving universal interop.

It's a devastating argument.

Recently IBM held a ODF Interoperability Workshop at the OpenOffice annual conference in Barcelona, Spain. The Workshop was organized by IBM's Rob Weir. In this blog, uber document processing expert Florian Reuter opens the lid for a peek at what really happened at the Workshop. And it wasn't "interoperability". As a Novell employee, Florian is unable to comment publicly as to what really happened in Barcelona. But to those who are not under IBM's oppressive thumb, the results of this fiasco are laughable. Sure IBM and Rob Weir are busy threatening individuals, and bribing the press to suppress the reality of this horrific ODF ZERO Interop demonstration. But that doesn't mean those who really care can't talk about it. The OpenDocument Foundation has of course been screaming about the ODF interop problems. But we've been focused on the big picture of world wide market requirements; the need for ODF to be compatible with existing file formats and interoperable with existing applications - including Microsoft documents and applications. Of course, this level of interoperability was outside the scope of ODF purpose and work. We apologize for daring to suggest that real world implementation issues are important and ought to be considered. but there remains the issue of ODF interoperability which also sucks beyond belief. The exact same principles apply. ODF interop depends on complete application independence, and ODF remains bound to OpenOffice. Now i'm someone who has publicly championed ODF interoperability. I've spent years championing the fact that ODF can meet all market requirements for interoperability. And whatever credibility i thought i might have is now destroyed by that very public and very in your face lack of interoperability.

So here i am, with any credibility i might have ever had resting on the pretensions of a self proclaimed clown (a hef="http://wordnet.princeton.edu/perl/webwn?s=antic">his description not mine). Can R

Let's do this again:

Recently IBM held a ODF Interoperability Workshop at the OpenOffice annual conference in Barcelona, Spain. The Workshop was organized by IBM's Rob Weir. In this blog, uber document processing expert Florian Reuter opens the lid for a peek at what really happened at the Workshop. And it wasn't "interoperability".

As a Novell employee, Florian is unable to comment publicly as to what really happened in Barcelona. But to those who are not under IBM's oppressive thumb, the results of this fiasco are laughable. Sure IBM and Rob Weir are busy threatening individuals, and bribing the press to suppress the reality of this horrific ODF ZERO Interop demonstration. But that doesn't mean those who really care can't talk about it.

The OpenDocument Foundation has of course been screaming about the ODF interop problems. But we've been focused on the big picture of world wide market requirements; the need for ODF to be compatible with existing file formats and interoperable with existing applications - including Microsoft documents and applications.

Of course, this level of interoperability was way outside the scope of ODF purpose and work. We apologize for daring to suggest that real world implementation issues are important and ought to be considered. But there remains the issue of ODF interoperability which also sucks beyond belief.

The exact same principles apply. ODF interop depends on complete application independence, and ODF remains bound to OpenOffice.

Now i'm someone who has publicly championed ODF interoperability. I've spent years championing the fact that ODF can meet all market requirements for interoperability. And whatever credibility i thought i might have is now destroyed by that very public and very in your face lack of interoperability.

So here i am, with any credibility i might have ever had resting on the pretensions of a self proclaimed clown (http://wordnet.princ

Dana Blankenhorn posted this article back in March of 2007.  It was right at the time when the OASIS ODF TC and Metadata XML/RDF SC (Sub Committee) were going at it hammer and tong concerning three very important file format characteristics needed to fulfill a real world interoperability expectation:

.... Compatibility - file format level interop -
:::  backwards compatibility / compatibility with existing file formats, including the legacy of billions of binary Microsoft documents

....... Interoperability - application level interop-
::::::  application interoperability including interop with all Microsoft applications

Explosive compatibility - interoperability study concerning ODF and MOOXL!  This has Florian's signature written all over it, and it goes right to the heart of the matter.

David A. Wheeler submitted a comment to the OASIS ODF TC outlining his concerns with this publication.  He suggests that a few minor changes to ODF could greatly improve compatibility - interop issues.  He also figures out that OpenOffice - ODF has more features than MSOffice - MOOXML.  Wha the doesn't ge is that it is these new and innovative features that continue to increase the difficulties of implementing ODF in real world business process workgroups!

David also ignores the fact that the TC jus tvoted down the Novell "LIt Enhancement Proposal" which was specifically designed to address the compatibility - interop issues outlined in this odf-converter blog!  Given a choice, the ODF TC members chose the new and innovative features of the interop breaking Sun-KOffice "List Enhancement Proposal".   

The List Enhancement Proposal discussion was so contentious and focused on personal destruction as to represent a total break down of the ODF concensus process.  There is no way that either the Foundation or Novell will ever contribute another compatibility - interop enhancement proposal given the personal assault and determined oppostion of Sun to compatibility - interoperability initiatives.

The hard lesson the Foundation learned is that if you oppose Sun, you'll get booted out of OASIS!

The lesson Novell learned is that they are better off working through Ecma 376 to resolve these issues that the public demands be addressed.

Notice the last line in David's comment, "In any case, the MUCH, MUCH longer list of problems with Microsoft XML format isn't our problem." 

During the contentious List Enhancement Proposal and the compatibility - interop related Metadata RDF/XML discussions, ODF members freque

These are the same guys who just voted against the Novell List Enhancement Proposal that did exactly what the odf-converter blog claims needs to be done if the compatibility-interop problems are to be resolved!

Thanks to Paul for digging this up. Who would have guessed that years later, these same issues hang like a dark shroud on the future of ODF? Note also that June 1st of 2007 was the cut off date for ODF 1.2 proposals and recommendations. The OpenFormula and Metadata SC's were rushing to make the cutoff. The List Enhancement proposal itself was just one of many enhancements submitted by Florian Reuter in November of 2006, designed to greatly improve ODF compatibility with MSOffice "ODF". By November of 2006, thanks largely to the Massachusetts Pilot Study, there were a number of ODF plug-ins for MSOffice. All were capable of producing perfectly compliant ISO 26300 ODF, but falling far short of public expectations of high fidelity interop with OpenOffice ODF. Sound familiar? Everyone knew that it was only a matter of time before Microsoft was pressed into providing MSOffice ODF support. There was no doubt that they would face the exact same interop challenges as the many independent plug-in efforts. Hence the stepped up efforts by many at the OASIS ODF to "fix" ISO 26300! At the time of the List Enhancement Proposal, we had increasing evidence from the many pilot studies that ODF was impossible to implement in business and workgroup environments where the MSOffice productivity environment was the defining platform. ODF was not designed to be compatible with MSOffice or the binary documents so critical to business processes bound to this environment. OpenXML was designed exactly to be compatible with these environments. Unless ODF fixed it's compatibility/interoperability problems there was no way for the independent plug-ins to provide a reasonable ODF implementation alternative to OpenXML. And even if Microsoft did produce an MSOffice ODF compliant with ISO 26300, these productivity environments would remain entirely locked. The world expected ODF to be compatible, interoperable, Web ready, and fully capable of cracking open the iron grip Mic

Well well well. We knew that IBM had access to the secret binary blueprints back in 2006. Now we know that Sun ALSO had access!
And why is this important? In June of 2006, Massachusetts CIO Louis Gutierrez asked the OpenDocument Foundation's da Vinci Group to work with IBM on developing the da Vinci ODF plug-in clone of Microsoft's OOXML Compatibility Pack plug-in. When we met with IBM they were insistent that the only way OASIS ODF could establish sufficient compatibility with MSOffice and the billions of binary documents would be to have the secret blueprints open.
Even after we explained to IBM that da Vinci uses the same internal conversion process that the OOXML plug-in used to convert binaries, IBM continued to insist that opening up the secret binaries was a primary objective of the OASIS ODF community.
For sure this was important to IBM and Sun, but the secret binaries were of no use to us. da Vinci didn't need them. What da Vinci needed instead was a subset of ODF designed for the conversion of those billions of binary documents! A need opposed by Sun.
Sun of course would spend the next year developing their own ODF plug-in for MSOffice. But here's the thing: it turns out that Sun had complete access to the secret binary blueprints dating back to 2006!!!!!!
So even though IBM and Sun have had access to the blueprints since 2006, they have been unable to provide effective conversions to ODF!
This validates a point the da Vinci group has been trying to make since June of 2006: the problem of perfecting a high fidelity conversion between the billions of binaries and ODF has nothing to do with access to the secret binary blueprints. The real issue is that ODF was NOT designed for the conversion of those binary documents.
It is true that one could eXtend ODF to achieve the needed compatibility. But one has to be very careful before taking this ro

Andy UpDegrove takes on the issue of Microsoft submitting their proprietary "XML alternative to PDF" proposal to Ecma for consideration as an international standard.  MS XML-PDF will compliment ECMA 376 (OOXML - OfficeOpenXML) which is scheduled for ISO vote in September of 2007.  Just a bit over 60 days from today.

Andy points out some interesting things; such as the "Charter" similarities between MS XML-PDF and MS OOXML submisssions to Ecma:

MS XML-PDF Scope: The goal of the Technical Committee is to produce a formal standard for office productivity applications within the Ecma International standards process which is fully compatible with the Office Open XML Formats. The aim is to enable the implementation of the Office Open XML Formats by a wide set of tools and platforms in order to foster interoperability across office productivity applications and with line-of-business systems. The Technical Committee will also be responsible for the ongoing maintenance and evolution of the standard.   Programme of Work: Produce a formal standard for an XML-based electronic paper format and XML-based page description language which is consistent with existing implementations of the format called the XML Paper Specification,…[in each case, emphasis added]

If that sounds familiar, it should, because it echoes the absolute directive of the original OOXML technical committee charter, wh

Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~

Interesting comment from Simon Phipps: maybe we'll see ODF interoperability in versions 1.3 or 1.5? Note to Simon: It's been five years now since owrk on ODF began! Why not do something about the piss poor ODF interop now? Do we really need to wait another five years? ODF interop problems can be fixed with a simple vote to change the wording in Section 1.5, the Compatibility Clause, from should to must. Today compliance is optional, and it's killing ODF!!!! And this clown says we were out of our depth? He's out there peddling zero interoperability amongst ODF ready applications, with over 550 million users unable to convert their billions MSOffice documents to ODF, and we're the ones out of our depth? Although ODF began a noble and honorable effort to gift mankind with an open universally interoperable XML strucutred format also application, platform and vendor independent, things have changed. The big vendors have taken over, and turned this once noble effort into a shameless marketing war that's invaded international politics as it has corrupted international standards orgs. Game Over! ~ge~

The First Law of the Interent is that of interoperability. Interop ALWAYS comes first.
Interop trumps innovation!!!
This is why the Interent changes everything. Innovation takes place within the bounds of ineroperabiltiy. Vendors of course rely on innovation as the primary means of market differentiation. They would of course champion innovative features. Interop on the other hand is a leveling force.

In this 2006 article Nick Carr lays out the history of office productivity applications, arguing the Office 2.0 is really Office 3.0 - the generation where desktop productivity office suites mesh with the Web. This article is linked to The Office question, December 18, 2007

In this 2006 article Nick Carr lays out the history of office productivity applications, arguing the Office 2.0 is really Office 3.0 - the generation where desktop productivity office suites mesh with the Web. This article is linked to The Office question, December 18, 2007

Great quote from Eric Knorr.  He hits the nail on the head here, pointing out the problem Office 2.0  Web Apps and SaaS apps face:  If these Web wonders have interoperability and high fidelity document exchange with MSOffice, their collaborative features are value added wonders for existing business processes and workgroup-workflow scenarios.  If, on the other hand they lack this level of interop - integration with MSOffice documents and processes, the value add becomes a problematic split in a business process.  The only way to overcome that kind of a split is to take the entire process.  Which is difficult for lightweight mashup happy web wonders to do.

Which leaves each and every one of these Office 2.0 - Web 2.0 - Saas Apps vulnerable to Microsoft.  As long as Micrsoft owns the interop-integration keys to MSOffice, the web wonders live a precarious life.  At any time Microsoft can swoop in and take it all.

Today, the MSOffice OOXML file format displays perfectly in a browser.  It's 100% web ready, but only the MS Stack of applications gets to play.  Web wonders are not likely to recieve a Redmond invite now or ever.

Which brings us to the issue of the da Vinci plug-in for MSOffice.  da Vinci is a clone of the OOXML plug-in for MSOffice, and fully leverages the same internal conversion process that OOXML enjoys.  It can achieve the same high fidelity "round trip" conversion that OOXML is capable of.  Maybe even better. 

The problem for da Vinci isn't conversion fidlelity.  Nor is it capturing  business process important VBa scripts, macros, OLE, and security settings.  da Vinci can do that just fine.  The problem is that da Vinci cannot pipe MSOffice developer platform documents into ODF!!  For the love of five generic eXtensions, called the iX "interoperability enhancements", which the OASIS ODF TC blew off, ODF

So, South Africa was watching closely the failed effort in Massachusetts to implement ODF?  And now they are determined to make it work? Good thing they left themselves a "pragmatic" out; "there are standards which we are obliged to adopt for pragmatic reasons which do not necessarily fully conform to being open in all respects."

Massachusetts spent a full year on an ODF implementation Pilot Study only to come to the inescapable conclusion that they couldn't implement ODF without a high fidelity "round trip" capable ODF plug-in for MSOffice.  In May of 2006, Pilot Study in hand, Massachusetts issued their now infamous RFi, "the Request for Information" concerning the feasibility of an ODF plug-in clone of the MS-OOXML Compatibility Pack plug-in for MSOffice applications. At the time there was much gnashing of teeth and grinding of knuckles in the ODf Community, but the facts were clear. The lead dog hauling the ODf legislative mandate sleigh could not make it without ODf interoperability with MSOffice. Meaning, the rip out and replace of MSOffice was no longer an option. For Massachusetts to successfully implement ODf, there had to be a high level of ODf compatibility with existing MS documents, and ODf application interoperability with existing MS applications. Although ODf was not designed to meet these requirements, the challenge could not have been any more clear. Changes in ODf would have to be made. So what happened?

Over a year later,

Rick Jellife weighs in on the OpenOffice ODF- MSOffice OpenXML interop embroglio. His take is to focus on Classes of Fidelity, providing us with a comparative table of fidelity categories. I wonder though if this über document processing approach is anywhere near consistent with the common sense meaning of interoperability to average end-users? IMHO, end-users interpret "interoperability" to mean that compliant applications can exchange documents without loss of information. "..... In my blog last year Is ODF the new RTF or the new .DOC? Can it be both? Do we need either? I raised the question of whether ODF would replace RTF or DOC. I think this issue has come back with a bang with the release of Office 2007 SP2, and I'd like to give another pointer to it for readers who missed it first time around.... "...... OASIS ODF TC has some kind of conformance and testing wing at work, but it is not at all clear that they will deliver anything in this kind of area. Without targetting these classes, ODF's breezy conformance requirements means that ODF conforment software can deliver vastly different kinds of fidelity, yet still accord to the letter of the law (and, indeed, to the spirit of the ODF spec, which allows so many holes) which will cause frustration all-around....." Ouch!

Short slide deck of Barbara Held's February 28th, 2007 EU IDABC presentation. She introduces ODEF, the "Open Document Exchange Format" which is designed to replace both ODF and OpenOfficeXML. ComputerWorld recently ran a story about the end of ODF, as they covered the failure of six "legislative" initiatives designed to mandate ODF as the official file format. While the political treachery surrounding these initiatives is a story in and of itself, the larger story, the one that has world wide reverberations, wasn't mentioned. The larger ODF story is that ODF vendors are losing the political battles because they are unable to provide government CIO's with real world solutions. Here are three quotes from the California discussion that really say it all: "Interoperability isn't just a feature. It's the basic requirement for getting your XML file format and applications considered"..... "The challenge is that of migrating our existing documents and business processes to XML. The question is which XML? OpenDocument or OpenXML?" ....... "Under those conditions, is it even possible to implement OpenDocument?" ....... Bill Welty, CIO California Air Resource Board wondering if there was a way to support California legislative proposal AB-1668. This is hardly the first time the compatibility-interoperability issue has challenged ODf. Massachusetts spent a full year on a pilot study testing the top tier of ODF solutions: OpenOffice, StarOffice, Novell Office and IBM's WorkPlace (prototype). The results were a disaster for ODF. So much so that the 300 page pilot study report and accompanying comments wiki have never seen the light of day. In response to the disastrous pilot study, Massachusetts issued their now infamous RFi; a "request for information" about whether it's possible or not to write an ODF plugin for MSOffice applications. The OpenDocument Foundation responded to the RFi with our da Vinci plugin. The quick descriptio