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

[Peter Vandenabeele]

On 2/4/07, Thomas Zander <zander at kde.org> wrote:
> And they _are_ ODF files.

I believe we are getting in a symantic discussion here. And it is good we
have it, so we all come up with a consistent naming for the different types
of documents. I make a few proposals below and I am open to any proposal.
I am sure we will find a naming convention we can agree on.

If you prefer to call the entire class of documents "ODF", fine, may I then
suggest to call them:

  "ODF without extensions"  (aka "ODF")
  "ODF with extensions"       (aka "ODFX")

as 2 derived classes ? I am open to any other proposals for names ...

If we accept this naming scheme, then users (administrations) may clarify
their policy to :

  "mandatory use of _ODF_ from that date on"

to

  "mandatory use of _ODF without extensions_ from that date on"

or

  "prefered use of _ODF without extensions_
     and
   mandatory use of _ODF with extensions_ if full fidelity with MS
Office is required."

or

  "mandatory use of _ODF without extensions_ for NEW documents
     and
   mandatory use of _ODF with extensions_ for EXISTING documents"

or other combinations.

The problem is that it would be really confusing to give both "ODF without
extensions" (aka "pure ODF") and "ODF with extensions" (aka "ODFX") the
.odt , .ods and .odp extension. On many operating systems, these
file name extensions (that last 3 or 4 characters after the dot) also have
a deeper meaning indicating the file format. And then it becomes really
confusing, since .odt / .ods / .odp files will indicate both "ODF without
extensions" and "ODF with extensions". That is why I suggested using
".odt" (etc) and ".odtx" (etc) to avoid that confusion. Any other naming
scheme can be used, as long as it clearly marks the 2 different classes
of documents.

> Even if they don't fit in your view of open :)

Indeed. But that is just my current (young) view and I suggest we agree
to disagree on this and let the customers decide over how they want to
use the technology and do the migration.

So, to repeat myself, a plug-in might be useful if it adds these 2 features:

* it provides a run-time flag to select "ODF" (without extensions) or
   "ODFX" (with extensions) as output format.

* the resulting "ODFX" (ODF with extensions) files have a different
   filename extension (e.g. .odtx etc.).

This will allow each organisation to set it's policy for itself (only "ODF",
only "ODFX" or a mix) and the different filename extension will reduce
the confusion over different interop behaviour of both document types.

> > So this proposal replaces:
> >
> > EOOXML + ODF ==> ODFX + ODF
>
> Exactly.
> There is no need for the old .doc and the Ecma 376 (aka eooxml) fileformats
> anymore. Just ODF.

2 classes ... but strictly speaking indeed both a subclass of "ODF"

>  With the unkown data saved so the app that requires that
> data still has access to it.
> The foundation is looking for a good way to merge ODF and ODFX, as you so
> lovingly named it, in the 1.2 spec to make sure we really have just one
> format.

If we can make all "extensions" that are required for full fidelity processing
of all historical MS Office formats to be fully, openly and freely specified in
ODF 1.2 or a later version, well, than we have the perfect solution,
discussion closed and major congrats to the ODF 1.2 team !

> > The advantage of the ODFX documents is that they guarantee full
> > round-trip fidelity in MS Office.
>
> Yes. Or, more generically speaking;  It allows the user to not loose the
> data he created over the last 15 years.

The data is also not lost if it is stored in its original MS formats. And since
MS Office is required in both cases for full fidelity access to the documents, I
see little advancement in getting rid of the vendor lock-in from Microsoft
Office.

But I can see the advantage that if we reach closer to 100% of the content
of a document that can be stored in standard ODF (not in extensions), then
it is easier for e.g. light-weight applications to interprete the part
of the contents
that is not in the extensions, than if they also had to speak full MS EOOXML.

> The 'no' part is that new documents will be created in new applications and in
> a new format. Free from any blobs. Many features people thought they needed,
> but actually were only for the MS monopoly can be dropped by never giving
> them priority to be implemented.

I certainly agree here. In all cases, we should promote ODF "free from
any blobs"
(aka "pure ODF" and "ODF without extensions") to be used for new
documents. That is where the "flag" would also help, so that we can
clearly instruct people to
save all documents in "ODF without extensions" unless they have a particular
reason to allow extensions.

HTH,

Peter