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