[odf-discuss] A story of TIFF

[marbux]

[more]

On 2/3/07, Alex Hudson <alex at stratagia.co.uk> wrote:
>
> I think you're missing Daniel's point.
>
> An "MS Office interop subset" is an interesting idea, but entirely
> beside the point: if OOo can generate ODF files that are too complex for
> MS Office to read, even with a "perfect" converter, that is too bad and
> maybe we want to address that. It's a different issue though: Daniel is
> talking about the MSO -> OOo ODF trip, not the other way around.
>
> If the MSO converter generates ODF which is only 65% ODF and is 45%
> Microsoft binary-encoded-as-XML-stuff, that's not really ODF, and the
> ability to a. not lose that data and b. mark it "Here be Dragons"
> doesn't actually get you any further to understanding it, or having that
> data in _real_ ODF.

I think you've missed something somewhere along the line. 65 % interop
with OOo was what was achieved by the August version of da Vinci that
was based on ODF 1.0 with its optional foreign metadata tags. My
understanding is that the current version using the proposed ODF 1.2
changes already achieves near-perfect interop in both directions
except for the ODF page layout engine tags that can not be mapped to
MS Word IMBR. That is why an MS Office interop subset of ODF is needed
as the work-around to Microsoft's bad attitude toward interop with
other vendors' apps.

>That's the problem: setting up proprietary ODF formats
> which only certain apps have any hope of reading. It's detrimental to ODF.

I won't say much here because your quoted sentences were apparently
based on a misimpression of what the current da Vinci build does. But
I suspect you're looking at the issue from the traditional viewpoint
of applications as an end point. If you look at the problem from the
viewpoint of software as a router of information in a business process
such as a SOA that includes Microsoft Office in the chain of apps,
then I think you have to balance the drawbacks against the benefits.
The benefits to users are tremendous. They don't have to use MS Office
just to maintain interop with it; they should be able to use ODF apps
and have interop not just with MS Office but also with the fleet of
apps that hopefully will support ODF 1.2.  But I note that full
fidelity is way more important than full interop in this scenario.

If ODF were a set of formats designed only for a single office suite
and nothing else, and flawless interop with MS Office was not a market
requirement, then I'd say, sure, keep all the foreign metadata out.
But we're not living in a perfect world. MS Office, by my rough
estimate, has somewhere between 72 and 75 per cent of the office suite
market share. The more that ODF can eat into that market share, the
sooner Microsoft will have to support ODF natively itself.

ODF has already picked up a lot of the easy pickings, but from my
perspective it's going to become increasily more difficult to pick up
additional market share. Look at the precedents page. We've been
picking up way more new government programs and programs that  don't
have enormous data retention requirements like software for students
than we have been adding programs that require migration of lots of
Microsoft binaries to ODF. And if you want a sane phased migration
instead of a rip-and-replace, you've got to have full fidelity
conversions. Otherwise, you're going to have to accept data loss and
most governments can't do that legally. And I doubt that many
enterprises would want to accept data loss as the price tag for
migrating to ODF.

The Foundation guys are the only ones I've heard of who are even
trying for full fidelity and full interop. I'm planning on keeping an
open mind on what they come up with.

Best regards,

Marbux