[odf-discuss] Interop between multiple standards and multiple applications [new thread]

[Peter Vandenabeele]

On Nov 15, 2007 6:03 PM, M. Fioretti <mfioretti at nexaima.net> wrote:
...
> Here I disagree with your analysis:
> On Thu, Nov 15, 2007 14:11:40 PM +0100, Peter Vandenabeele
> (peter at vandenabeele.com) wrote:
...
> > But what if 2 _really_ open standards would come into existance?
> > Quite a nightmare, especially with increased globalization of
> > economy, culture, politics, ... That is IMO a very fundamental
> > problem that needs to be addressed.
>
> There is a fundamental difference between the OOXML/ODF case and the
> others you have mentioned: all those things, plugs, TV signals, paper
> size etc... are *physical*, ie supporting them both means
> manufacturing and maintaining twice the tools, trays, packaging,
> technicians skills etc... a huge cost indeed at many levels.
>
> In many cases the real cost isn't even in "more than one open,
> official standard", is that vendors aren't (cannot be?) forced to
> produce compatible products where no standards exist, think to cell
> phones and their chargers.
>
> File formats, instead, are immaterial, you can store both of them on
> the same hard drive. IF both OOXML and ODF were equally open and they
> both remained around for decades or more... it would be terribly
> stupid, of course, but it would only affect the few programmers who'd
> have to deal with both formats, and the people paying them.
>
> A real cost for sure, but nothing comparable with keeping multiple
> paper trays, power plugs etc...

I differ here.

Indeed, the manufacturers of physical goods standards need to deal with both
formats, but that's a finite, solvable problem (just like making a shaver that
operates on 110V/220V). Once you made a tray which accepts A4 and "letter",
both paper sizes do fit exactly. Yes, it costs a little more money to
manufacture
such paper trays and such shavers, but that is a finite cost.

The deeper problem is that, while the shaver works perfectly on 110V/220V,
the document transition between 2 different document formats will _remain_
imperfect forever, users running into interop problems every time, over and
over again, until we find a solution for that.

The solution I propose is to define an interop subset/core profile, that limits
itself to only those features that can be adequately represented in ODF and
adequately handled by the current market leading office applications. Yes,
that may mean we refrain from defining e.g. a "frame in a frame" (as we saw
nicely demonstrated at the ODF Camp in Barcelona), but at least then we will
know that we have created a document that can be imported (into the internal
document object model) and rendered "exactly" (by as far "exact" rendering
is possible in descriptive format, because it is e.g. dependent on
font availability,
which differs, nearly non-overlapping, from OS to OS). I become increasingly
convinced that such an "interop subset" really makes sense for those users
that prefer interoperability (between multiple office applications and multiple
Operating Systems) over maximum feature set.

> So considering this and the fact that there is only ONE really open
> office file standard which is realistically usable today... I'm not
> that worried about this last problem.

For acceptance of ODF in the real world, it is important that we make it is
as compatible as possible with the current market leading office application.
Only then, will we get traction with end-users. This is important, so that
the use of ODF is not only seen as a "burden" imposed top-down onto
the users. But I am not prepared to do anything outside of the ODF
standard to reach that goal, rather stay inside a slightly smaller subset
inside the ODF standard to improve interop.

Using such an interop profile on "our" side, will not guarantee that we
(ODF users) can read all the exported .doc documents (and represent
all those features in .odt format upon conversion), but at least it will
guarantee that any .odt (and ODF in general) that we _write_, can be
read and rendered exactly by the users of the current market dominant
office suites. And maybe this is the most important direction to start
with. "We" know and understand there are problems upon importing e.g.
.doc files and are prepared to tolerate such transition problems for a
short time. But the new users, that are unaware of (and uninterested in)
the ODF interoperability details, are able to fully and reliable read the
ODF documents we send them (using the proposed "interop subset",
so that we are sure all features can be represented correctly in the
document object model of the current dominant office applications
(MS, OO.o, KOffice, Symphony, ...)).

Peter