The conspiratorial tyranny of Rob attending a plugfest (and other delusions)

[robert_weir@us.ibm.com]

marbux <marbux@gmail.com> wrote on 06/19/2009 11:21:55 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.
> 

Again, I'm sorry reality could not be more accommodating to your idée fixe
, but most of the problems we found were related to defects in the 
implementations, not defects in the standard.   I came prepared with every 
published copy of the ODF standard on my harddrive as well as current 
drafts of ODF 1.2 and OpenFormula.  I also had a shortcut to the ODF TC's 
JIRA defect tracking system, so I could enter any defects found, on the 
spot. I announced that I was willing to do this on the wiki.  In the two 
days of the workshop I did not have the opportunity to enter any defects 
against the standard, because no new ones surfaced. 

That doesn't mean the standard is perfect, of course, but it does indicate 
that not all interoperability problems are caused by defects on the 
standard.  Can you acknowledge that much, Paul, that some interoperability 
problems are caused by implementation defects?  Can you see that 
possibility in the abstract?  And doesn't it also make sense that the 
deficiencies in the standard which most impact real-wolrd 
interoperability, such as lack of spreadsheet formulas, would tend to be 
already well-known and are already being worked on by the TC?


> 
> >> > 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.
> 

I agree that should's are not relevant to conformance.  But they are 
relevant to interoperability and interoperability tests are part of the 
charter of the OIC TC.  So what's your problem?

> 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.
> 

You're kidding, right?  We had a 2-month public discussion on the OIC TC 
chartr plus an OASIS member comment period.  So a comments were solicited 
for 3 full months.  Although I drafted the initial charter language, many 
other hands contributed to the final text.  Consensus was required, and 
achieved, among the initial members of the OIC TC, as is required by 
OASIS.


> 
> >> 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.
> 

The concept of an interoperability plugfest is a recurring pattern in 
engineering which has been successfully applied to many standards.  It is 
hardly surprising that multiple groups will find it interesting. 

> >
> > 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.
>

Allegiance?  It is not like we took an oath or anything. 

When I'm invited to a plugfest, I'm 100% for the plugfest.  When I'm 
chairing a TC meeting, I'm 100% for the TC.  When we go out for a beer, 
I'm 100% for the Grolsch. 

It would have been rather rude and disruptive of me to suggest that all of 
the implementors who traveled so far to attend a plugfest, that they 
should turn off their computers and not actually run their programs or 
scenarios, but instead we should sit down with a red pencil and read 
through the standard for where a 'should' could be changed to a 'shall'. 
That is not the purpose of a plugfest.

 
> >> 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.)
>

This was not an OASIS meeting, nor an ODF TC meeting.  The invitation from 
the Dutch government was sent to IBM, not OASIS, and IBM decided to send 
me to represent them.

> 
> 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.
> 

ODF TC meetings are Mondays at 10am EDT.

> 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.
> 

There are several modes of standardization, depending on whether you are 
talking about a new technology that has no implementations, or a 
technology that has several existing implementations.  I think we're 
closer to how ISO C++ came about.  Based on the original Bell Labs work on 
the C-Front compiler, there were soon around 10 competing C++ 
implementations.  Each one implemented its own slightly different dialect. 
 Standardization allowed the implementors to agree on a core C++ language 
and library, including some new features, but also rationalizing some of 
the divergent behaviors.  So standardization was a convergence of 
implementations.  When ISO C++ was published there were already conformant 
implementations.  So obviously vendors were changing their implementations 
and implementing the standard as it was being drafted.  Since standards 
are typically written by the same parties that write the implementations, 
there is no "wagging" in one direction or the other.  Standards and 
implementations co-evolve simultaneously.


-Rob

> Best regards,
> 
> Paul
> 
> -- 
> Universal Interoperability Council
> <http:www.universal-interop-council.org>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
opendocument-users-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: 
opendocument-users-help@lists.oasis-open.org
>