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

[marbux <marbux@gmail.com>]

On Fri, Jun 19, 2009 at 12:12 AM, <robert_weir@us.ibm.com> wrote:
> marbux <marbux@gmail.com> wrote on 06/19/2009 07:45:10 AM:
>
>>
>> Hey, Rob, for some reason the Plugfest wiki doesn't seem to provide
>> any pointers to the the relevant specification requirements. In fact
>> it doesn't even disclose what version(s) of ODF were being tested.
>> Makes it seem as though what was being checked was app < > app
>> sameness in test results, rather than conformance with the spec and
>> whether the spec might be ambiguous in relevant regard.
>>
>
> Of course we were running app<->app scenarios.  That is the point of a
> user scenario.  After all, users don't sit down with a single
> implementation and a a copy of the ODF standard, do they?  This was an
> interoperability plugfest, not a conformance workshop. The goal was to
> find a broader class of defects, including implementation defects, where
> interoperability was broken.

The corollary would seem to be that no one was checking whether the
corresponding sections of the specification were ambiguous. I.e., the
machinery was not put in place for the Plugfest to provide useful
feedback to the TC. 'Tis as I suspected.

But how did you objectively determine that spec ambiguity was not a
factor except in two cases where fixes had already been submitted for
ODF 1.2? Sounds a bit problematic if no one had the spec when they
compared test results.

Methinks what you said before is unraveling, Rob.


>> > Of course we should design tests for the should's as well as the
> shall's.
>> > Most standards have recommendations and they are worth testing,
>>
>> Not as part of "conformance" testing, the word you chose for the OIC
>> TC Charter. Recommendations can be safely ignored without affecting
>> the validity of a claim of conformance.
>>
>
> The TC's name is the OASIS ODF Interoperability and Conformance TC. Taking
> notice of the should's is certainly relevant for interoperability.

Give it up, Rob. You're just evading  a valid criticism by talking
past what I said. The OIC TC Charter says the TC will be testing
"conformance" with the "recommendations." "Shoulds" may be relevant to
interoperability in the sense that they might point the way toward a
need to replace "should" with "shall." But they don't have an iota of
relevance to the issue of conformance.

That's what you get when you whip out your own charter without seeking
consensus at a TC formation meeting. Nobody gets a chance to bring
errors to your attention.


>> Whether you want to instigate plugfests or not, you are the co-chair
>> of the ODF TC and that TC's responsibility is to fully specify the
>> standard, not to convene plugfests. If your plugfest fever leaves you
>> without time to ensure that ODF specifies the conformity requirements
>> that are essential to achieve the interoperability, then I
>> respectfully suggest that it's time for you to stand down from the
>> co-chairmanship and a new chair be found who's willing to commit to
>> repair of the specification rather than plugfests.
>>
>
> Neither I nor the ODF TC "instigated" the plugfest. It was sponsored by
> the Dutch government and organized by the Open Doc Society.  I was honored
> to be invited and participate.

If that is true, then I apologize for that error. I had this weird
idea that your incessant pushing for plugfests might have had
something to do with the event's instigation.

>
> In the end I serve at the pleasure of the members of the ODF TC and
> whenever a majority of them desire to replace me, there is a defined
> mechanism in place for them to do it.

Says nothing about your priorities or your willingness to bring the
specification up to what's required, Rob. I wasn't calling for your
removal. I was calling on you to resign if your allegiance to
plugfests outweighs your willingness to do what's required for the
spec.

>> Your repeated suggestions here that application-level interop work
>> should be given a higher priority than repair of the spec cannot be
>> reconciled with your legal responsibilities as the co-chair of the ODF
>> TC.
>
> I'm being pragmatic.

No. You're ducking the merits of what I said again. As co-chair of the
ODF TC you have responsibilities that do not include plugfests,
particularly plugfests not designed to produce useful feedback for the
TC. As a TC co-chair, you are cloaked with the apparent authority of
OASIS itself and are expected to leave your loyalty to IBM behind when
you act in that capacity.  American Society of Mechanical Engineers v.
Hydrolevel Corp., 456 U.S. 556 571, 574 (1982),
<http://laws.findlaw.com/us/456/556.html>. ("The anticompetitive
practices of ASME's agents are repugnant to the antitrust laws even if
the agents act without any intent to aid ASME, and ASME should be
encouraged to eliminate the anticompetitive practices of all its
agents acting with apparent authority, especially those who use their
positions in ASME solely for their own benefit or the benefit of their
employers.")  (Standard-setting organization held liable under the
Sherman Act for acts of its agent cloaked with its apparent
authority.)


Identify the most important real-world interop break
> points from the user's perspective and do what is necessary in the code to
> fix them.  If the standard is found to be the source of the problem, then
> fix the standard as well.   Interoperability begins with an open standard,
> but it doesn't end there.

So when do we get the open standard on your schedule so we can begin
to work toward standard-based interoperability? The law says those
conformity requirements essential to achieve the interoperability have
to be there when a standard is adopted. Instead, we have a grossly
under-specified mess. Wrong when it's OOXML; wrong when it's ODF.

Other initiatives such as plugfests,
> implementation notes, conformance test suites, validators, reference
> implementations, etc., all play a role.  This is not a trivial engineering
> problem to solve, so we should not deny ourselves the use of proven
> effective tools.

I think the full specification of an open standard comes first, Rob.
Standards are supposed to wag implementations, not the other way
around.

Best regards,

Paul

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