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

[marbux]

On 2/5/07, Daniel Carrera <daniel.carrera at zmsl.com> wrote:
> On Mon, 2007-02-05 at 14:08 -0800, marbux wrote:
> > 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.
>
> 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.
>From the day you finish your migration, you can set your OOo or
KOffice seats to use full ODF rather than the interop subset and they
should only need to switch back in the future if they have to
roundtrip a document with someone outside your organization who is
still using MS Office. As time goes along, the percentage of active
files that include Microsoft dark objects should swiftly decline.

If there is no interest in the organization in migrating to ODF apps
rather than continuing to use MS Office, organizations still have an
opportunity to minimize the number of expensive MS Office seats they
require via da Vinci and ODF apps that support the ODF MS interop
subset. E.g., set up an instance of MS Office as the automated router
of documents generated using ODF 1.2i-enabled OOo or KOffice into the
Microsoft-bound business processes.  Net result: MS Office loses
market share; ODF apps gain market share.

> > 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.
>
> I understand that point too. If we could show that ODF can represent
> everything Ecma 376 can, then there is no need for Ecma 376.

I thought of a rather huge issue in that regard that hadn't occurred
to me before. That is that there demonstrably is no need for an
international standard for Microsoft to implement Ecma 376. It already
has. The only reason for an Ecma 376 international standard is
Microsoft's desire to regain its eligibility for government software
procurement without fully supporting ODF. There is no market
requirement for migrating legacy binary files to OOXML. The market
requirement is for migrating them to ODF, the only relevant
international standard.  The proof is on the Fellowship's Precedent
page.

But I am
> not confident that using (legal) extensions of ODF and putting binary
> dark objects in them, proves this.
>

I don't think that we need to show that everything in MS Office can be
mapped to ODF. As just discussed, the Microsoft argument for Ecma 376
as a standard is circular and founded on the erroneous premise that
there is a market requirement for migrating legacy binary files to
Ecma 376. It's an argument that eats its own tail. The market
requirement is for migrating those files to ODF, or more accurately
for migrating those files to ODF during a migration phase and then
moving on using only ODF. I doubt that Microsoft will be able to come
up with many governments that would say they would rather migrate to
Ecma 376 than to ODF. And it is important I think, that Ecma/Microsoft
based their market requirement argument in the specification on the
need to *migrate* the binary files to Ecma 376 with "high fidelity,"
not on any need to round-trip them.

But even were Microsoft able to show that some of its features can't
presently be mapped to ODF (and it still hasn't done that), that
raises other questions. E.g., are such features important enough to
demonstrate a market requirement worthy of an international standard?
Could they not be implemented as extensions of the ODF standard?

I think you have to ask such questions because if any international
standard could be duplicated or deprecated simply because one vendor
managed to create a new feature that isn't presently supported in the
standard, then no standard is safe. To boot, I've now come up with the
law that says harmonization with ODF is mandatory. It's illegal to
bring forward a proposed standard that inconsistently duplicates or
overlaps with an existing standard. The exception is when there is a
proposal to replace a standard with a new one because the new one is
less trade-restrictive. Ecma 376 doesn't qualify and Microsoft/Ecma
have not formally proposed that ODF be superceded in any event.

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.

> Consider a fictitious example (a thought experiment): Ogg is a really
> cool audio format. Suppose that the Xiph foundadation submits it to ISO
> to become the ISO standard for digital audio. You can insert digital
> audio in ODF by invoking the same "dark object" method that the plugin
> does. Just add a new namespace, create a tag, and dump the data in it.
> You can store it in any binary form you like. Ogg, MP3, or heck, just
> raw data. And this is a valid ODF file in exactly the same way that the
> Foundation's files are. Of course, ODF apps won't know what to do with
> that data, but you can certainly make a plugin for any audio player that
> reads the data successfully from that ODF file with 100% fidelity.
>
> Should this prove that Ogg is not needed? I think we can agree that it
> doesn't. For this reason, I don't expect any argument based on section
> 1.5 extensions of ODF to carry much weight.
>

I do if they reach a stage where we can show that the problem is being
dealt with in the ODF standardization process. We're up against a
full-fidelity migration argument, not an interop argument. If we can
show that the full fidelity issue is being addressed, I think we've
done enough on that score.

> 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. That left
Microsoft free to mess with it. But with ODF being an International
Standard, Microsoft must produce conformant ODF or it is out of the
government software business. So "embrace and extend" really can't
work in this situation, assuming we get the conformance section of the
spec made bullet-proof.

I don't want to see ODF files tied to MS Office the way many
> web pages are tied to IE. And I fear that the Foundation plugin is,
> effectively, MS-ODF.
>

I see it primarily as a valuable migration tool that won't be needed
post-migration except for the occasional rendering of a legacy
document in its original state and the occasional MS document that
gets sent to an ODF shop. That is, if we win the Ecma 376 battle.

Best regards,

Marbux