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

[Daniel Carrera]

On Tue, 2007-06-02 at 04:29 -0800, marbux wrote:
> > Yes, I understand the benefits of a phased migration. I understand that
> > it can be the difference between migrating or not migrating at all. But
> > what are you migrating to? You are migrating to daVinci+MS Office,
> > making ODF files that are just as tied to MS Office as they were before
> > (_more_ tied actually, as long as daVinci's ODF interop is less than
> > OOo's 85%).
> 
> I think you're missing that once your migration is complete, you only
> have to keep a copy of MS Office + da Vinci around in case it becomes
> important to view or print a legacy document in its original form.

I would agree with that if ODF applications could then read the ODF
files with good results. I understand, and agree, that if out of 500
computers you migrate 499 to (say) OOo and keep one copy of MS Office
for the rare occasion where OOo is not good enough, that is a major
victory. And I would love to see that happen a lot. But I fear that 65%
interop is not enough to achieve this. If OOo cannot read more than 65%
of the content in the files, the agency will not move the 499 computers.

I also understand the merit you see in adding binary blobs to the files.
The situation you envision is like this (correct me if I'm wrong):

* Agency has 500 computers on MS Office.
* Agency moves all its files to ODF + binary blobs.
* Agency moves 499 computers to OOo.
* If you edit a file in OOo you don't lose the binary blob. If you are
ever required to reproduce the file with perfect accuracy, you can use
your one remaining MS Office computer to do so.

The argument has good merit. It is a tempting proposition.

The only problem with this scenario is that if OOo can't read the ODF +
binary blob files with _good_ results, the agency still can't move the
499 computers.

When the plugin achieves good interop you will see me warm up to it a
lot. I will still point out other problems, but a major problem would
have been resolved. I think I would even begin to recommend it to
whatever contacts I get when this interop occurs.

The other problem I present is the fear that MS or others might follow
your precedent and that we might start seeing MS-ODF, WP-ODF, etc.

I don't comment on your recent point about Ecma 376 because I'd like to
think about it. But on a first reading, it sounds sensible enough. If we
can find a better argument against the market requirement of Ecma 376
that would be great. And we just got a 3-month extension to do it in. :)

> The upshot is that I'm no longer worried about the
> can't-use-ODF-because-it-doesn't-support-all-of-our-features argument.
> It's smoke and mirrors.

:-)


> > HTML is a relevant example. Remember how MS extended HTML? They added
> > their own tags, and made IE-HTML. Today Firefox, Konqueror, Safari,
> > Opera and every other browser has to struggle displaying many websites
> > because they are "optimized" for IE. The situation has improved, it used
> > to be really bad. It took an enormous amount of effort to deal with
> > Microsoft's extensions to HTML.
> >
> > I worry that something similar might happen with ODF. I don't want to
> > see MS-ODF.
> 
> There is one huge difference between the HTML situation and ODF. HTML
> has never been adopted as an International Standard.

HTML is ISO/IEC 15445.


> But with ODF being an International
> Standard, Microsoft must produce conformant ODF or it is out of the
> government software business.

Let's make sure then, that the definition of "conformant" does not
include using section 1.5 to add extensions.


Best wishes,
Daniel.
-- English is a marriage between German and French.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.opendocumentfellowship.com/pipermail/odf-discuss/attachments/20070206/efc2bc82/attachment-0001.pgp