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

..........
Convergence -
cross platform interop
:::::::::  the portable XML document
promise of being able to move content/data/media rich document
packages across desktop - server - device and Web information
systems.  Another way of expressing this would be the exchange
of portable XML documents with data bindings across desktop
productivity environments, enterprise publication-content-archive
management systems, SaaS, SOA and Web 2.0

Organizations the
world over are at an important inflection point.  They need to
move existing documents, applications and processes to XML. 
Once there, the explosively rich digital civilization emerging around
Web based collaborative computing is within reach.  The big
enchilada being SaaS, SOA and the Web 2.0 AJAX-REST mashup interop
that promises to shatter all the restrictions of big vendor
controlled "interop".

The problem is that they have
to answer this question, "Which
XML?  OOXML, or ODF?"

Microsoft
has provided a free OOXML plugin for most of the installed base of
500 million MSOffice bound desktops.  The key aspect of the
OOXML plugin is that it effectively answers the three criteria above;
the issues of compatibility, interoperability and convergence.

The
problem is that the OOXML Plugin, (otherwise known as the Microsoft
Compatibility Pack), is entirely bound to Microsoft legacy Windows
platform dependencies and, newly emerging Vista Stack dependencies
(as in desktop-server-device-web MS platform mashup).  There is
simply nothing open or application - platform independent about the
Microsoft application specific implementation of OOXML. 

So
the question is, can one implement ODF meeting the same
criteria?

Massachusetts, California and Denmark have all
answered that question with a resounding NO.  And Lord knows,
Massachusetts tried!  Tried but failed.

Massachusetts
even conducted a year long "Pilot Study" regarding the
issues and barriers they would need to overcome to successfully
implement ODF.  The result of the Pilot Study was the conclusion
that the only way any government could successfully implement ODF was
through the use of ODF Plugins for MSOffice.  Plugins that would
effectively clone the OOXML Plugin for MSOffice, except that they
would map the applications internal in-memory-binary-representation
of a document to ODF instead of to OOXML.

The reason for this
need is that there are two barriers to every ODF implementation. 


The first barrier is that of high fidelity document
conversion : the application “imbr”
binary <> ODF conversion.

The second barrier is the
"impossible" one.  This is the barrier presented by
years of MSOffice bound workgroup-workflow business process
development.  Because of the second barrier, any ODF
implementation must be able to integrate into existing business
processes. 

The Pilot Study discovered and exposed the
grip these day to day MSOffice bound business processes have on
governments.  The Pilot Study also revealed the incredible cost
of trying to rip out and replace MSOffice; having to re engineer
these bound business processes, line of business integrated apps and
complicated assistive technology add-ons for ODF alternative
solutions like OpenOffice.

In fact, there was no proof that
one could even recreate / re engineer the bound business processes
for OpenOffice at any cost, let alone a reasonable cost.

The
Pilot Study determined that it is too costly and way too disruptive
to go the "rip out and replace" route all of the major ODF
vendors were insisting upon.  This would be Sun, IBM, Novell and
Red Hat!

Meanwhile, the big ODF vendors all back ODF mandate
legislation that would force government IT to do the impossible -
implement ODF no matter what the cost, disruption or technical
difficulty.

Undaunted, Massachusetts waded into the
difficulties the big ODF vendors had with an ODF Plugin clone of the
OOXML MSOffice plugin.  The results were a disaster, with IBM
and Oracle fully supporting the da Vinci - InfoSet plugin proposal. 
And Sun in total opposition. 

Red Hat never got invited
to the IBM-Oracle da Vinci dance.  Novell was invited, but ended
up pursuing and hiring the OpenDocument Foundation's da Vinci
architect, Florian Reuter, as a key player of critial importance to
their secret deal with Microsoft!  With the failure of the Louis
Gutierrez da Vinci - InfoSet initiative, Louis resigned.  And
Novell hired Florian. 

On his first day at work for
Novell, the deal with Microsoft was announced, and Florian was
immediately tasked with the challenge of writing the Novell OOXML
Translator Plugin for OpenOffice. 

As it turns out, this
was a critical obligation for Novell as their part of the Microsoft
deal.  Most importantly, the OpenOffice plugin provides the
first non Microsoft implementation of OOXML.  Furthermore, the
Novell OOXML enabled version of OpenOffice is the default on 90% of
all LiNUX distributions, and has become the cornerstone of subsequent
Microsoft "interoperability - patent protection" deals with
Linspire, Xandros and TurboLinux.

So, what does this all
mean?  And what does it have to do with the March OASIS ODF
issues running in the background of Dana's three card Monte
article?

Faced with the Pilot Study results, and seeing up
close and personal the challenge of the two barriers to ODF
implementations, the OpenDocument Foundation had to re write our da
Vinci plugin so that it could match exactly the round trip fidelity
of the OOXML plugin for MSOffice.  Exactly!

Interestingly,
this can be accomplished through the advanced use of the ODF 1.0
"Conformance Clause".  This is Section 1.5 of the ODF
specification, and was written into the spec by the legendary reverse
engineer expert, Stellent's Phil Boutros.  The purpose of the
conformance clause is exactly to provide a means for converting the
billions of binary documents to ODF.  Using the Conformance
Clause, da Vinci could even perfect the round trip of these documents
throughout a MSOffice workgroup-workflow.

The problem is that
use of the Conformance Clause breaks interoperability with
OpenOffice!  OOo only partially implements and supports the
Conformance Clause; pathetically limiting support to paragraphs and
text spans.  None of the important structural issues of lists,
fields, tables, sections or page dynamics are supported.  And
that totally breaks any hope of interop with da Vinci MSOffice.

Note
that OpenOffice ODF also breaks interop with near every other
application implementation of ODF.  The difference is,
Massachusetts needed OpenOffice to be fully interoperable with da
Vinci MSOffice if they were to pull off an effective migration to
ODF.  Meaning, enabling Massachusetts to freely choose, without
business process compromise or disruption, their future purchase of
applications.

So an important consideration for Massachusetts
was Sun and OpenOffice support for what was then called the "ODF
1.2 iX "Interoperability Enhancement" Proposals.

If
there was ever to be interoperability with the kind of round trip
fidelity demanded by MSOffice bound business processes, the ODF
community had to rally around the ODF iX proposals, and support for
internal ODF Plugins that could match the OOXML plugin conversion
process.

On July 3rd, 2006, the first version of the ODF 1.2
iX proposal was submitted to Louis Gutierrez and his ITD staff. 
A version was circulated to OASIS ODF TC and Metadata XML/RDF
interested members.  On August 3rd, 2006, a second "composite"
version of ODF 1.2 iX was submitted.  And, on November 20th,
2006 a third "simplified composite" version was provided to
the OASIS ODF TC (the failure of ODf in Massachusetts having taken
place in October of 2006).

The first item on the November 20th
ODF 1.2 iX proposal list to be submitted as a formal proposal to the
OASIS ODF TC is known as the "List Override" Proposal. 
It was submitted by Florian Reuter, in his new role as the Novell
developer working on the OOXML Translator Plugin for OpenOffice!

Did you catch that? Florian Reuter,
the primary architect of the da Vinci plugin and now Novell developer
tasked with the Microsoft-Cleverage-Novell (the deal!) OOXML-ODF
Translator Project to perfect the OOXML Translator Plugin for
OpenOffice; posted and then submitted the first of the ODf 1.2 iX
“Interoperability Enhancement” Proposals as needed by the
MS-Cleverage Translator Project!

What happened next is truly tragic but
very revealing. Sun went after Florian and the iX proposals with an
unprecedented viciousness and personal vehemence that went way beyond
the total breakdown of the traditional ODf consensus process.
Interestingly though, Florian was able to present his “List
Enhancement Proposal” arguments in terms of a comparative
requirements table that argued the importance of compatibility,
interoperability and convergence (see above :).

Sun triumphed. The Novell proposal
went down to bitter defeat, and with it any illusion that the OASIS
ODf TC would ever support the compatibility, interoperability, and
convergence needs of ODf with respect to Microsoft documents,
applications and bound business processes. And, the OpenDocument
Foundation ended up getting booted out of OASIS.

Needless to say, the critically
important ODf 1.2 iX “Interoperability Enhancement” Proposals are
dead. And so is any hope of migrating existing MS documents,
applications and processes to ODf XML. The OASIS ODf TC has answered
the world's questions about which XML file format they should migrate
to, “OOXML or ODf?” The only option for those who are bound to
MSOffice is to use the OOXML plugin, and migrate to the highly
proprietary, application and platform dependent, even stack
dependent, OOXML.

Throw in the data binding Smart
Documents model, and OOXML-Smart Docs becomes the foundation of a 15
year lock in for desktop bound business processes that will no doubt
migrate to the Vista Stack center, the Exchange/SharePoint Hub. What
other choice is there if there is no way to migrate those same
MSOffice bound business processes to ODf Hubs? Thanks a pant load
Sun!

Which brings me to this finish. John
Bosak, founder of both the W3C XML and OASIS ODf, recently stated the
official
Sun position as that of supporting ISO approval of OOXML as an
international standard (DIS 29500). Sun's reason? Only OOXML is
compatible-interoperable
with the legacy of billions of MS binary documents and Microsoft
applications:

“We
wish to make it completely clear that we support DIS 29500 becoming
an ISO Standard and are in complete agreement with its stated
purposes of enabling interoperability among different implementations
and providing interoperable access to the legacy of Microsoft Office
documents.”

Read it and weep. Sun has opposed
every single compatibility-interoperability initiative proposed to
the OASIS ODf TC, beginning with the very
first meeting in December of 2002! This opposition continued
through the battle to implement ODf in Massachusetts, and on into the
Microsoft-Novell-Cleverage OOXML-ODF Translator project.

And now Sun claims that they must
support OOXML as an international standard after nearly five years of
blocking any and every effort to improve ODf interoperability with
Microsoft documents, applications and processes?

The world seriously needs to revisit
the 2004 “$2 Billion” deal between Sun and Microsoft because
we've been had. I believe there is evidence aplenty that Sun
traded ODf universal interoperability and the monopoly busting
threat of an OpenOffice lead community charge based on that
interoperability for a sweet sweet hardware deal. A hardware deal
guaranteeing Sun machines in Microsoft data centers coupled with
Redmond support anywhere enterprise and governments needed superior
high performance integration with Microsoft applications.

It's a deal that saved Sun. It's also
a deal that demanded Sun cheat everyone else in the ODf Community out
of their sincere efforts to create a truly universal file format.

Yeah, we've been had. But this is
hardly the end of it.

~ge~