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

[robert_weir@us.ibm.com]

marbux <marbux@gmail.com> wrote on 06/19/2009 05:51:19 AM:


> 
> Please point me to all those interop defect reports IBM has filed
> against the specification, Rob? I'm apparently suffering a huge memory
> loss. Not. And even though we deal with a hypothetical situation
> rather than reality, aren't you presupposing that the TC would adopt
> the same solution for the problem that you've implemented in your app?
>  I can already hear the cries like KDE's that if the spec doesn't
> permit a choice between ordered list tuples and ordered list triples
> they'll have to write a converter for their legacy documents.
> 

For example, the major theme of ODF 1.1 was accessibility, aka 
interoperability with screen readers for blind users.  IBM took a leading 
role in analyzing the specification to find problems in this area and 
proposing fixes.

We're certainly aware of interoperability issues in Symphony, but our 
analysis shows that they are either implementation defects or 
specification ambiguities that are already known and fixed in ODF 1.2. 

I'm looking at this very pragmatically, Paul.  Let's do what is necessary 
to improve interoperability, without any presumptions of who or what is to 
blame.  I'm not adverse to improving the specification if that is where 
the problem is.  But in practical terms, only code can exhibit 
interoperability problems, since users only run code.  So I think an 
approach, like used at the Plugfest, where we concentrate on user-facing 
scenarios and determine the source of the error and address that error. 
This is an engineering-based approach. 

You, on the other hand, seem to be advocating an approach that merely 
mandates interoperability and then assumes that the problem goes away. But 
it doesn't work that way.  Whether interoperability is mandatory or 
voluntary, the engineering effort required to achieve interoperability is 
exactly the same.  Changing 1,000 should's to shall's accomplishes exactly 
nothing for the user.  In fact it is far easier to get vendors to agree to 
change a should to a shall after they have changed their code (or at least 
committed to changing their code) than to make a change in the standard 
that will automatically leave every implementation non-conformant.  So 
again, the emphasis on finding the practical interoperability problems via 
user-facing scenarios, finding the source of the interoperability problem, 
agreeing on a solution, and implementing the solution.

-Rob