This is the fifth of the six major iX - interoperability enhancement proposals submitted to the OASIS ODF TC - SC between July 2006 and February of 2007.

This particular iX proposal lead to the "List Enhancement Proposal" donnybrook that consumed the OASIS ODF TC for the next six months, ending with the OpenDocument Foundation being booted out of OASIS in May of 2007.

The six iX proposals were all different approaches to the same basic problem: ODF was not desinged to be interoperable with MSOffice documents, applications or bound processes. The proposals come out of the OpenDocument' Foundation's efforts to save ODF in Massachusetts.

ODF iX repressents a subset of ODF designed to grealty improve compatibility with MS binary and XML formats. With the ODF iX subset, the da Vinci plug-in would be able to convert the billions of MSOffice binary and xml documents with a very high level of fidelity, and do so within the bounds of "round trip" business processes.

The most basic iX approach was to add five generic elements to the existing ODF specification. The five generic elements would cover lists, tables, fields, sections, and page dynamics (breaks).

It is a well known fact that these five areas of incompatibility between OpenOffice ODF and MSOffice binaries represent 95% of all conversion fidelity problems. MSOffice has one way of implementing lists, and, OpenOffice has another. These application specific implementation models are irreconcilably different.

It's also true that the applicaiton specific implementation models are directly reflected in each file format. So applications implementing ODF must also implement the OpenOffice model for lists, fields, tables, sections and page dynamics-page positioning if they are to have any meaningful measure of exchange fidelity.

Perhaps the best of the iX approaches was that based on the innovative use of metadata to describe presentation-layout attributes. There were two submissions by OpenDocument Foundation members relating to this method. The first came in August of 2006 and was accepted as part of the OASIS ODF Metadata SC "Requirements" document. The second was submitted in February of 2007, also a s part of the Metadata CS work.

By April of 2007, when votes on both the "List Enahncement Proposal" vote and the "Metadata 1.2" were taken, the Foundation's proposals were eitther dropped or defeated.

In May of 2007, OASiS moved to enforce a rule change eliminating the ability of 501(c)3 non profit corporations to sponsor OASIS participants. This evisceration of our membership effectively ended the Foundation's role with OASIS ODF.

It also ended any hope of an ODF subset geared towrds interoperability with MSOffice and high fidelity conversion of billions of MS binary and xml documents.

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~

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, a few days after Sun
delivered their proprietary ODF plug-in for MSOffice, Massachusetts
announced that both ODF and MS-OOXML would be recognized as
implementable standards. (Good one Sun. Thanks a pant load.) 


Recent legislative hearings in Texas concerning a bill that
would mandate ODF as the only document standard, revealed something
very surprising.  There was direct testimony that out of the
entire Commonwealth of Massachusetts, only 24 desktops had
successfully transitioned to ODF. Whoops. Good thing they had the
Sun ODf plug-in :) 

With Exchange/SharePoint developer
hubs going down everywhere, automagically converting binary
documents  to MS-OOXML, and the MS-OOXML Compatibility Pack
plug-in effectively enabling workgroup conversions to MS-OOXML,
things do not look good for the future pragmatic
implementation of
ODF in Massachusetts. Or anywhere else for that matter.

The
needed changes to ODf emphasizing the need to meet the Massachusetts
defined market requirements of high level of ODf compatibility with
existing MS documents, and ODf application interoperability with
existing MS applications, were not made by the OASIS ODf TC.

So
i wonder just how closely South Africa has been watching
Massachusetts?

Not
that it's difficult to figure out.  In Massachusetts it all came
down to the sprawl of MSOffice bound workgroups where business
process document
exchange
required this difficult "high fidelity round trip"
conversion.  Not only does the ODF plug-in have to perfect a
consistently high fidelity conversion to ODF of these active
documents, but the documents had to be "round trip" ready
in terms of application use.

Round tripping is a killer for
ODf, with or without the inclusion of MSOffice desktops in any
workflow – document processing chain.  The specification was
designed to protect content
during extensive document exchange and processing chain use, but not presentation!

During
an effective document exchange, many applications must be
interoperable at the file format level.  For ODF this is limited
to "content",
with the assumption that each application will apply their own "presentation". 
Sometimes this is jokingly called the "let
a thousand presentations bloom but don't touch my data"
approach.  It's very consistent with the way document processing
experts view the world.

The "let
a thousand
presentations bloom"
approach is not however consistent with public expectations for ODF.


The public expects PDF quality of interop between
applications, where both content and presentation is preserved
throughout the document exchange process - unless and until the
owners of the document make changes. 

This dilemma
brings us back to that age old problem of interactive (as opposed to
PDF static) document exchanges being totally tied to specific
applications - right down to the version level. 

What
we found in Massachusetts is that the ODf implementation barrier was
due to MSOffice bound workgroups and business processes. And it
wasn't just the year long Pilot Study screaming this. They gave us
150 test documents representative of critical business processes
where uncompromising fidelity had to be maintained. And yes, the
documents were filled with our favorite structural conversion
problems of lists, tables, fields, sections and page dynamics. These
problems in turn can be attributed directly to the structural
implementation differences between MSOffice and OpenOffice.

Let's
take this issue to a higher level. The ODF barrier itself had two
problem points which we've expresses as the critical market
requirements for a high level of ODf compatibility
with existing MS documents, and ODf application interoperability with existing MS
applications.

The
first was that it's impossible to fully capture MSOffice feature sets
and specific structural implementation models in ODF.  The ODf
container is simply not designed for the high fidelity conversion of
MS binary or xml documents, which directly reflect the MS application
specific implementation model of basic structure