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

[Peter Vandenabeele]

On 2/4/07, Thomas Zander <zander at kde.org> wrote:
> On Saturday 03 February 2007 16:50, Peter Vandenabeele wrote:
...
> > If that is the case, I would prefer to be straight open about the problem
> > and just admit that interoperability between fully specified ODF and MS
> > Office is not perfect (on purpose, actually), and we will have to support
> > both formats a bit longer in those cases where we need full fidelity.
> > </personal non-official view>
>
> I see your point, but I disagree with your sentiment.
...
> The same goes for this case; companies (&governments) will NOT choose a
> solution that means they will have to support both the old fileformat and the
> new. Its too big a gamble.  And this is not my opinion, this is the opinion
> of several governments.  So its a given and we have to work with that.

Interesting. I think this touches the fundamental discussion on strategy
for migration.

Do I see correctly that we now have 2 visions on migration. And maybe even
in the same organisation, the optimal strategy may be different for different
use cases:

* some organisations prefer to call all documents "ODF", even if some
  of them contain pure "ODF" (where all contents of the file are fully, openly
  and freely specified) and others are really "ODFX" (ODF with "meta data",
  "foreign data", "extensions" that are not fully, openly and freely specified).

  In this scenario, full round trip fidelity with MS Office is considered as the
  most important criterium. Some solutions for this can be devised (e.g.
  the Foundation plug-in, the proposal of Daniel to extend the odf-converter
  project to also allow full fidelity by storing all non-translatable
features in
  extensions, and maybe others have other ideas).

  So this proposal replaces:

  EOOXML + ODF ==> ODFX + ODF

  The advantage of the ODFX documents is that they guarantee full round-trip
  fidelity in MS Office.

  The disadvantage is that full interoperability is lost for the ODFX documents:
  other applications (such as OO.o, KOffice), have no guarantee that they have
  a full view on the document. The hope is that the fraction of the
document that
  is non-fully specified reduces over time.

  But still, these are at least 2 formats.

* some people (like me) are currently not convinced that defining ODFX as a
   new mixed or intermediate format is the best general approach. I currently
   believe that it is better to stick to EOOXML + ODF and use measures to
   ensure that at least NEW documents are made in pure ODF and as much
   as possible new work flows use pure ODF.

   Maybe the idea of an ODF subset that is more easy to convert to EOOXML is
   an interesting idea to support this. Would this allow all "pure
ODF" documents
   of the subset to be imported without conversion loss into MS Office of
   converted to EOOXML ?

Now, if we let the customer choose, a logic conclusion might be to ask all
suppliers of plug-ins and converters if they can provide the following:

  A plug-in, converter that has an optional "full-fidelity" flag (like
a check-box in
  the "Save As" dialog), to let it save files either in:

  * "ODF" mode (full-fidelity == OFF):

     the exported file contains only fully specified ODF constructs
(no extensions).
     This guarantees full interop with all other applications that
process ODF. But,
     this export mode may be unable to represent all details of the document
     exactly.

     In a perfect world, the plug-in would be able to make it clear
during editing in
     MS Office which features can not be exported to pure ODF.

  * "ODFX" mode (full-fidelity == ON):

     the exported file may contain certain "foreign data". If the
plug-in is correctly
     implemented, this export mode guarantees full round-trip interop for
     documents when processed in MS Office + plug-in. But, this export mode
     will not guarantee full interop with other applications. To make
that clear to
     the users, I would prefer such documents are given the extension .odtx,
     .odpx, .odsx, etc.

Once the plug-in's support both modes, a technical comparison is possible on
the quality level for "pure ODF" and "ODFX" mode, and the customer can choose,
case by case which model for migration he prefers. I have a view on that, but as
you state above, others have a different view.

Would the plug-in providers be interested to add this option ?

For the Foundation plug-in, that would be adding the "pure ODF" mode (if not
already present ?).

For the odf-converter project, this would require implementing e.g. the idea
that Daniel brought up. Since that is Open Source, anyone could implement
that idea.

With this proposal, actual customers with real cases can decide, even on a
case-by-case basis.

Of course, all of these are just my personal ideas, not official statements.

Peter