Re: [opendocument-users] simple OO.org document goes awry in MS Office 2007 w/SP2 - what went wrong?

[marbux <marbux@gmail.com>]

On Tue, Jun 16, 2009 at 12:37 AM, <robert_weir@us.ibm.com> wrote:

> So any time the document does not interoperable, the end user cannot tell
> whether it is a bug in the authoring application, or a bug in the
> destination application, and whether any of these bugs are related to the
> standard.  The best thing to do is report it to the the vendors involved
> in the transaction, let them debug the issue.  If it ends up to be an
> issue in the ODF standard, then they should be able to propose any changes
> necessary.  In this particular cases, both vendors participate on the ODF
> TC, so they have direct access to make such technical proposals.

So I understand it, are you saying that every bug report I or anyone
else sends you on an interop failure between Lotus Symphony and other
ODF implementations will result in you promptly submitting a TC
proposal to fix the relevant spec(s) with as many mandatory interop
requirements as are needed to remove the relevant ambiguity if the
failure is due to an ambiguity or other flaw in the spec, Rob? And
that you'll shepherd that proposal through the TC and implement the
fix?

It's noteworthy, I think, that the bug reporting method you recommend
is the status quo ante and has not in nearly seven years produced a
single ODF specification that even attempts to specify the conformity
requirements that are essential to achieve interoperability.

There's been a historical problem with TC members who don't translate
interop failures into proposals to fix the specification accordingly.
Take the example of the lament by KDE KOffice's Thomas Zander:

"One thing I have always dreamed to be possible is that when I write a
doc in KOffice I can then open it in OOo to use that one feature
that's useful to me and then save it and continue in KOffice without
loosing lots of data.

"Its still a dream, of course. Most features are lost on opening and
saving it in OOo, but its a nice goal :)"

Thomas Zander, email to OASIS OpenDocument Adoption Technical
Committee mailing list (September 27, 2007),
<http://lists.oasis-open.org/archives/odf-adoption/200709/msg00032.html>.
No proposal to the TC to add some relevant metadata preservation
requirements.

Somewhat over a year later, KDE's Inge Wallin was quoted as saying,
"The use of the OpenDocument Format as the native file format. This
makes KOffice immediately compatible with a lot of other office
software, most notably OpenOffice.org. True, there still exists a few
incompatibilities, but most of those can be attributed to bugs that we
will fix as soon as we become aware of them." Rodney Gedda, KOffice on
Version 2.0, Extensions, and Being Like Firefox, ComputerWorld (28 May
2009) (quoting KDE's Inge Wallin),
<http://www.computerworld.com.au/article/304893/koffice_devs_version_2_0_extensions_being_like_firefox>.

So now we're told that the remaining problems are all on KDE's side of
the fence. If we are to lend credence to both the earlier and later
statements, one might infer that KDE and Sun worked out their interop
issues at the application level but didn't go to the trouble of
submitting corresponding proposals to fix the spec so others could
benefit from the knowledge they gained through their collaboration.

And certainly IBM hasn't exactly been a fount of proposals for fixing
the interop bugs in the spec. Instead, IBM pushes plugfests without
any corresponding push to get the knowledge thus gained into the
specification so others who didn't flit around the globe attending ODF
plugfests can benefit from the collaboration. Problematic, I think.
E.g., U.S. Federal Trade Commission and Department of Justice,
Antitrust Guidelines for Collaborations among Competitors (April,
2000), <http://www.ftc.gov/os/2000/04/ftcdojguidelines.pdf>, pg. 2 n.
5:

"These Guidelines take into account neither the possible effects of
competitor collaborations in foreclosing or *limiting competition by
rivals not participating in a collaboration* nor the possible
anticompetitive effects of standard setting in the context of
competitor collaborations. Nevertheless, these effects may be of
concern to the Agencies and may prompt enforcement actions."

How are those two proverbial guys with a garage going to enter and
compete effectively in the ODF implementation market if they missed
all those plugfests? See e.g., my comment to the office-comment list
last night:

"An ODF Plugfest is under way in The Netherlands. Interoperability
failures are being identified on a wiki.
<http://plugtest.opendocsociety.org/doku.php?id=links> ---> Scenarios.

"I propose that the TC add a corresponding work item to its agenda. The
work item would be: [i] to identify for each interoperability failure
reported on the linked ODF Plugfest site the relevant portions of each
ODF specification; [ii] to evaluate whether the interoperability
failure was due to ambiguity in an ODF standard and if so whether each
such ambiguity found exists in other versions of the standard; and
[iii[ to repair each such specification accordingly using normative
language and defined requirement keywords."

<http://lists.oasis-open.org/archives/office-comment/200906/msg00007.html>.

Are the interop failures identified at the Plugfest even going to be
evaluated by the participants to see if they're due to ambiguities in
the spec or are the participants just going to be negotiating fixes
that won't get translated into TC proposals? I'd really like a
straightforward answer to that question, Rob.

Every time a TC member does not translate user reports of interop
failures into proposals to fix the spec if the failures were due to
ambiguity in the spec, the TC (and later JTC 1) is deprived of any
benefit of the user's report.

On the other hand, if the user report goes initially to the TC rather
than to the vendor member, the vendor still has an opportunity to work
on the problem and even more incentive to propose a relevant fix for
the standard.

Of course there's the all too common user-seeking-support experience
where the app vendor blames the operating system and the operating
system vendor blames the app, but the user gets left without a fix.
Transposed to the ODF app < > app situation, it's a lot less
time-consuming and expensive to blame the other vendor's app than to
figure out what's wrong with ODF, develop a proposal to fix it, and
then buck the proposal through the ODF TC.

In summary, sending the interop failure reports to the vendors is an
untrustworthy process that can result in data loss between the user
and the ODF TC. On the other hand, the vendor is deprived of no data
by the report being sent to the TC instead. The TC will log the report
in its issue tracking system and the TC will decide what to do about
the report. It's an action forcing system. But there's nothing forcing
vendors to report interop failures to the TC and they have incentives
not to do so.

Nearly seven years is time enough to proclaim reliance on vendors to
submit interop proposals to the ODF TC a failed experiment. Past time
for a different procedure.

Best regards,

Paul E. Merrell, J.D. (Marbux)


-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>