[odf-discuss] strategy for ODF migration (was: A story of TIFF)

[marbux]

I think a few important things are being overlooked in the discussion
of so far of ODF and ODFX. I'll notice that much of the discussion in
the TC uses ODF 1.2i as the shorthand for what Peter refers to as
ODFX, with the "i" referring to the proposed ODF 1.2 "interop"
features.

While I agree that a sane administrator would prefer not to have more
rather than less filetypes in the administered system on general
principle of reducing complexity, there are compelling reasons for
doing so in the specific case. I see most of those advantages best
illustrated in the situation of an enterprise's migration from MS
Office to ODF apps, although there are other relevant use cases. I'll
discuss these use cases in the context of full fidelity, without
noting that in many of the cases discussed below, full interop would
be better than full fidelity. I address full interop only in the
contexts where it is critical.

Right now, a huge barrier for enterprises migrating to ODF apps is
posed by the necessity of doing a complete rip and replace of all
relevant software overnight. That doesn't allow phased migration at a
sane pace. But if you have full fidelity, you can migrate at your own
pace, e.g., migrating your trainers first, then migrating other people
one at a time as the trainers and the people to be migrated have
overlapping time in their schedules.

If the people migrated can continue to participate in the
Microsoft-bound remaining business processes' workflows without fear
of data loss, then you can also work on modifying the workflow engine
scripts as needed, testing them among the pool of folks who have
migrated. You can have a migration plan that doesn't require rip and
replacement of all relevant software at once.

The *only* market requirement specifically identified by the Ecma 376
draft standard that can not already be fulfilled by ODF is the
migration of Office legacy binary formats to Ecma 376 itself. Ecma 376
identifies "full fidelity" in such migrations as the major market
requirement. We have no corresponding goal or market requirement
identified in the ODF standard at this time. So we have to swim
upstream at ISO on that issue. An unfulfilled market requirement is a
threshold requirement for a new International Standard. We either
convince the national bodies we can fulfill that market requirement
with ODF or we are in a much weaker position.

So point 1: There is a reasonable market requirement for full fidelity
*during* migrations from Microsoft formats to ODF.

Next, there is the problem of enterprises that have migrated to ODF
needing to interact programmatically with others who still use MS
Office. E.g., inter-enterprise exchange of digital documents, such as
a corporate need to interact with government offices that still use
Microsoft Office, or one I am far more familiar with, the need for law
firms to round-trip documents with clients and other law firms.

So point 2: There is a reasonable market requirement for full fidelity
round-tripping *after* migrations from Microsoft formats to ODF. It is
beyond our powers to require that all users migrate to ODF
simultaneously and the need to interact with MS Office will continue
after people migrate. To the extent that such interactions are
automated, the requirement of full fidelity simply cannot be ignored.

Next, while we have the ability to add any needed tags to ODF should
anyone ever bring forward Office features that cannot be supported
using the existing ODF tag set, we lack the ability to require
Microsoft to add features to its apps to support ODF. no one has
stepped forward with a solution for mapping the more featureful tags
in ODF to Word documents without declaring an ODF interoperability
subset. That problem exists whether the path chosen is the
Foundation's plugin approach or the ODF > OOXML approach. Full
fidelity in round-tripping cannot be achieved without solving this
problem.

So point 3: Absent a better solution not yet proposed, full fidelity
round-tripping with MS Office can only be achieved by declaring an
interop subset of ODF.

Next, (and this touches on areas that I think really need discussion),
I see the need for the ODF MS Office interop subset as a potentially
short-term solution. My assessment -- on which I frankly admit I could
be wrong -- is that Microsoft's resistance to generating conformant
ODF is temporary, and an even shorter term phenomenon if it loses its
bid for Ecma 376 to be adopted as an ISO standard. Just as with its
previous efforts to avoid producing conformant HTML, if ODF becomes
widely adopted, Microsoft will eventually be forced to support it. And
if it loses its Ecma 376 as an International Standard play, Microsoft
is left   in the position where it must choose between fully
supporting ODF or bowing out of the government office software
business as well as much of the enterprise market as well. That's a
legal requirement under two different international treaties.

So at the point Microsoft buckles, we would be left with a situation
where Microsoft could conform to ODF by supporting only the interop
subset declared by the ODF standard. That is unless we find a creative
way to word the conformity requirements that has the effect of
requiring Microsoft to do more. E.g., would Microsoft then be
permitted to stash dark objects in ODF foreign element tags? As it
stands with ODF 1.0, the answer is yes.

So point 4: A formally declared interop subset might not be the best
way of aproaching the problem unless we can do a much better job of
explaining in the conformance section of the standard precisely when
the inclusion of dark objects is permissible. E.g., by formally
declaring that the interop subset, the foreign element tags, and the
five proposed extensions for describing dark objects are only for use
in achieving interoperability with non-conformant applications and are
not to be used by conformant applications to store and describe their
own dark objects or for conformant applications to achieve interop
with other conformant apps (i.e., Microsoft couldn't just support the
interop subset and continue to flood the ODF market with dark
objects.). But I have not studied that issue enough to form an opinion
on whether that is a workable concept. E.g., I can not say at this
time that there can be no valid reasons for conformant apps to wrap
their own dark objects in the foreign element tags. So we may need
further definition in this area. It's a subject that needs discussion.

Best regards,

Marbux