Re: [office] List Proposal Vote Deadline on Wednesday

[Gary Edwards <gary.edwards@OpenDocument.us>]

I believe David and Thomas have correctly stated the case.  There is however one aspect missing from their analysis; the "round tripping" aspect.

Thomas is right that the decision between the Novell and Sun/KOffice List Proposals comes down to a trade off between an advanced list implementation model two primary ODF applications have agreed to implement, and, compatibility with existing file formats. 

David is right that both proposals will be able to handle the conversion of existing file formats into ODF 1.2.  That should work well for both proposals.

The "problematic" difference between the two proposals will only be evident when converting from the Sun/KOffice new list model back to existing file formats.  Which is to say that the Sun/KOffice list model is a one way conversion.  The Novell proposal is designed to accommodate a two way conversion.

Why does this matter?

For internal MSOffice ODF plugin converters, the Sun/KOffice list proposal is a killer.  Same for the MS-CleverAge-Novell Translator project.  They will be able to produce ODF 1.2 documents (with the Sun/KOffice list model) without problem.  What they won't be able to do is load (convert back to the in-memory-binary-representation) ODF 1.2 documents with the Sun/KOffice list model.  Any list structure in these documents would break.

The reason this "high fidelity round tripping" matters is a bit complicated but perhaps worth explaining.

The real world is not a clean slate.  MSOffice dominates both individual desktop productivity, and, more importantly, "workgroup-workflow business processes".  The distinction between "individual" and "workgroup" is critically important here.  Individual desktops can easily be replaced by ODF ready alternatives.  The conversion of existing documents to ODF is a one time, never look back process.  The "workgroup" problem is a far more difficult situation, defying the conversion to ODF with two barriers, not one.

The first "workgroup" barrier is converting the existing file format to ODF.  We can do that.  The second barrier however is that of the MSOffice bound business processes, line of business apps, and assistive technology add-ons that have been bolted onto the MSOffice developers platform over the past fifteen years.

It's important to note that an MSOffice bound business process demands that the exchange of workflow documents be perfect in terms of both content and presentation fidelity.  There is no room in these workflows for fixing the artifacts of conversion; so either conversion is of "perfect fidelity", or there is no conversion.  This is why workgroups must have perfect MSOffice version synchronization.  The exchange of documents that fall within the reach of this workgroup-workflow need for "perfect round trip fidelity" is the engine that mercilessly drives without compromise the infamous upgrade treadmill.

This is also the reason why OpenOffice and Linux desktops can not penetrate the bulk of the MSOffice dominated marketplace.  They are unable to fully participate in these workgroup-workflows. This is partly die to the fact that they are locked out of MSOffice bound business processes at the VBA - OLE application development/integration layer.  and it's partly due to the exacting demand workgroup-workflow processes have for "perfect round trip fidelity" at the document exchange layer.  Like i said, it's a two barrier problem.

It's very clear today that the governments of the world want to migrate their existing documents and business processes into XML.  The only question is, "Which XML?  ODF or MOOXML?"

IMHO, ODF wins this argument every time at the technical - open standards - reuse of standards levels.  But looses at the real world implementation level - where the real world problem of actually moving existing documents and business process to ODF must be overcome. 

Microsoft has of course provided existing versions of MSOffice with a MOOXML plugin that effectively converts existing binary documents and business processes to MOOXML.   Further, as they move documents into MOOXML using this MSOffice plugin (the XML Compatibility Kit), the MSOffice bound business processes are ready to migrate to the Exchange/SharePoint Hub by way of developer re writing.  This re write at the Hub level delivers extraordinary productivity gains.  So much so that much if not most of the worlds current MSOffce bound business processes can be expected to move to an Internet Hub based footing within the next three to five years.  By way of example, the US real estate industry has already made this transition.  Within 9 months twenty years of desktop productivity software systems were summarily replaced by Exchange/SharePoint Hub applications. The transition was fast because the productivity gains are extraordinary.

The reason governments have sought out and asked for ODF plugins and translators for MSOffice is that they can't tolerate nor afford the disruptive cost of ripping out and replacing existing business processes "at the desktop level".  They would like to "integrate" ODF alternative desktops into existing workgroups-workflows, but the two barriers are impossibly difficult to overcome.  So they ask for a third solution; that of ODF plugins and translators enabling existing MSOffice bound workgroups-workflows to transition to ODF without disruption of critical day to day business processes.  And over a three to five year period, they hope to transition these desktop bound business processes to ODF ready Internet Hubs where SOA, SaaS, XML, RDF and Web 2.0 technologies can be used to mesh together highly interoperable systems.  Systems that feature fluid but ad hoc document processing chains where every application service has one outstanding characteristic - the ability to speak fluent ODF transformation.

If the converter plugins and translators lose the ability to round trip with perfect fidelity - the two way conversion if you will - then governments are going to have to carefully consider the disruptive cost of a "rip out and replace" based transitioning of existing documents and business processes to ODF. 

Let me also state for the record my that primary concern with the list proposals has nothing to do with the "compatibility with existing file formats - round trip" issue - important as that might be to internal plugin converters and translators.  My primary concern is that there is something fundamentally wrong with a proposal where an application specific implementation method is having to be hard wired into the ODF specification - requiring other ODF ready application to embrace the new list implementation model if they want to fully participate in ODF document exchange chains.  If applications are unable to innovate on top of ODF, and have to turn to the TC to hard wire into the spec their innovative implementation methods, then we have a serious flexibility problem.  More serious than just lists. 

And there is that small problem of the ODF charter and all our claims to be "application independent".  What do we say now?

This vote is a clear statement as to what the ODF 1.2 TC believes to be important objectives.  The Sun/Koffice list proposal is a tradeoff, offering what is no doubt a very cool and innovative approach to list implementation, but at a cost to "compatibility with existing file formats.  The Novell proposal attempts to let us have our cake and eat it too.  Personally i really like the fact that Novell approaches the problem at the "flexibility" layer, trying to preserve our fabled claim that ODF is application independent.

In the end, i'm very happy to have the TC go on record having considered every angle of this issue imaginable.  That's as it should be.
~ge~

David A. Wheeler wrote:

For some reason the voting system will not let me vote "abstain", so I'll record my "abstain" vote here on the mailing list.

Why?  Well, I want to make sure that (1) a SINGLE proposal is accepted (for interoperability's sake), and that (2) the accepted proposal is sufficient for current and future users.  As far as I can tell, EITHER solution will be able to fully handle today's documents as well as those of the future, including MS Word binary files.  So I'm voting "abstain", and will be delighted with the acceptance of EITHER approach.

To my understanding, Oliver/Thomas (Sun/KOffice)'s proposal uses triples (ID, style, level) to designate numbers, while Florian's proposal uses the (style, level) tuples with an optional style-override markup if needed.  Florian's approach is more similar to the approach taken by MS-Word, which makes translation of existing Word documents slightly easier.  The Oliver/Thomas approach is more complex, which is a negaive.  It's not exactly the same as any current applications, which is also a negative, but since it's coming FROM two implementors, that's less of a big deal... especially since the proposal doesn't seem that hard to do.  But the Oliver/Thomas approach seems to me to be much more flexible and capable.  As far as I can tell, the Oliver/Thomas approach should be able to easily represent any document from MS Word, as well as some really complex numbering schemes.  Since both models appear to meet the needs of Office applications, I think either makes sense.

I'd like to see WHATEVER approach is chosen implemented soon by at least one implementor, to make sure that there are no unforeseen issues.  In this case I think it's unlikely to be a problem with either approach.

My thanks to everyone for sticking things out to conclude with TWO workable solutions.  Two is a lot better than zero.

--- David A. Wheeler