Re: [opendocument-users] The conspiratorial tyranny of Rob attending a plugfest (and other delusions)

[marbux <marbux@gmail.com>]

On Fri, Jun 19, 2009 at 6:12 AM, <robert_weir@us.ibm.com> wrote:
> marbux <marbux@gmail.com> wrote on 06/19/2009 11:21:55 AM:
>
> 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.

Rob, saying this as gently as I can; but I do not trust your
ability/willingness to frankly evaluate the specification for
weaknesses. You really made a display of ignorance in your charges
that Microsoft's implementation of formulas was non-conformant with
ODF 1.1, quoting chapter and verse from spec portions that stated no
mandatory requirements. Even your best shot was wide of the mark
because you blinked past the
there-are-no-rules-about-what-elements-and-attributes-have-to-be-supported
chunk of the conformance section which nullified the one "requirement"
you pointed to.

And being nauseatingly familiar with the gruesome quality of the spec,
I think it somewhat amazing that you would say on the one hand that
implementers got it wrong whilst claiming that the spec was
unambiguous other than those two defects you had already caught. Why
did those implementers get it "wrong" if the spec is so clear?

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

Rob, there is no standard in the ODF "standard." You and I are not
going to be able to have an intelligent conversation before you're
ready to frankly deal with reality instead of trying to pretend there
is an ODF standard. If ODF is going to become a standard, it's a
salvage job and has to be approached as such. Can't happen while
you're in public denial.

Can you acknowledge that much, Paul, that some interoperability
> problems are caused by implementation defects?

Do I believe that software can have bugs? Yes. Do I believe there's
enough specified in ODF to create interoperable implementations
without reference to anything but the spec? No. Do I believe that the
sorry state of the specification had something to do with the interop
bugs found at the Plugfest? I'd put it well above 95 per cent
likelihood. Garbage in/garbage out. Do I believe that you understand
the difference between application-level interoperability and
standard-based interoperability? Yes. Do I believe that your push for
plugfests and mimicking the behavior of the code base your company
shares with Sun Microsystems is tantamount to an admission that the
ODF specification is in very sorry shape? Yes.

Can you see that
> possibility in the abstract?

Once there is an ODF standard, yes. Before then, the likelihood of the
spec's under-specification not being responsible for the vast majority
of interop failures is vanishingly small.

 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?

It would make sense to me but it isn't happening. I do read the TC
email archives, Rob, and watch the agenda. Spreadsheet formulas, yes,
because David Wheeler carried that ball, not one of the big ODF
vendors. But what about:

1.  Full-featured editors available that don't write
application-specific extensions to the formats?

2.  Interoperability of conforming implementations mandatory?

3.  Interoperability between different IT systems either demonstrable
or demonstrated?

4.  Profiles developed and required for interoperability?

5.  Methodology specified for interoperability between less and more
featureful applications?

6.  Specifies conformity requirements essential to achieve interoperability?

7.  Interoperability conformity assessment procedures formally
established and validated?

8.  Document validation procedures validated?

9.  Specifies an interoperability framework such as CDRF?

10. Application-specific extensions classified as non-conformant?

11. Preservation of metadata necessary to achieve interoperability mandatory?

12. XML namespaces for incorporated standards properly implemented?

13. Optional feature interop breakpoints eliminated?

14. Scripting language fully specified for embedded scripts?

15. Hooks fully specified for use by embedded scripts?

16. Standard is vendor- and application-neutral?

17. Revision history fully specified?

18. Digital signatures adequately specified?

19. Encryption methodology adequately specified?

20. Presentation layer adequately specified?.

21. Document settings adequately specified?

I could keep going and you know it. But you maintain this pretense
that all is hunky dory with the spec. And you, your company, and its
echo chamber continue spreading the ODF Interop Myth whilst painting
just about everyone who expresses a loud public desire for spec repair
with your Microsoft paint brush or some other personal attack.


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

Viewed narrowly, my problem is that the OIC Charter speaks nonsense
when it says it will design conformance tests for recommendations.
Viewed more broadly, my problem is that just about everything that can
be tested for conformance is already covered by validation against the
schema. To get to darned near any other mandatory requirement you have
to assume conformance requirements that don't exist and assume that
language in the conformance section does not exist like the "no rules"
clause.

Viewed still more broadly, my problem is that any conformance testing
other than validation against the schema is pretty much a waste of
people's time until the spec is fixed and there are requirements to
test that have some relevance to interoperability. .

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

Technically accurate but materially misleading. You pulled your
charter rabbit out of your hat mere days before the formation meeting
was closed. So really only the 30-day OASIS member comment period.

 Although I drafted the initial charter language, many
> other hands contributed to the final text.

But all behind closed doors. Your charter was presented as fait
accompli at the end of the formation meeting. It's tragicomic that
apparently no one pointed out the problem with testing recommendations
for conformance. That's a real howler. I was rolling on the floor
laughing about it the first time I read your charter. Course I
couldn't comment on it then because I'd been blocked from further
participation in the meeting. But I shared it with a few other people
who were just plain shocked.

Consensus was required, and
> achieved, among the initial members of the OIC TC, as is required by
> OASIS.

Yup. And everyone who thought the formation meeting was about
achieving consensus among participants in the meeting really learned
their lesson, didn't they?


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

Undoubtedly why you push plugfests instead of fixing the spec, Rob. It
makes sense to people who understand engineering but have no concept
of what standard-based interoperability is all about.

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

Nice pun but you ducked the merits of what I said by focusing on a
single word you plucked out of context.

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

Not what I said Rob. The question is more whether you're willing to
lead the ODF TC to sit down with that red pencil. Everything I see
says you haven't been willing to do that and still are not. Instead,
you pretend that the spec has only minor defects.

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

I was still talking about your willingness to lead the TC to produce a
spec that meets minimum legal standards rather than locking users into
your company's code base. But you evade again.

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

Doesn't answer the question I asked, Rob.

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

Sounds like the best argument for confining implementers to an
advisory role I've heard yet, Rob. So I guess we wait until SC 34 gets
ODF 1.2 to get the implementers back in their cages. Too bad. Just
delaying the inevitable, I think. But who knows, maybe you can rally
enough enough of the ODF Interop Myth True Believers using your
Microsoft paint brush to force ODF 1.2 through without big changes.
Stranger things have happened.

Best regards,

Paul

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