Re: discussion of LC comments on Extensions

Ah, I see the confusion.

At 02:13 PM 4/28/03 -0400, Mark Skall wrote:

>[...]You responded to the point that the new chapter will have a DOV 
>caution by saying that you disagree that we should tone it down because 
>"extensibility is #1 on my interoperability list of evils."  The DOV 
>caution (which I guess is the "toning down") applies to DOVs in general, 
>not extensibility which is just one of the many DOVs.

I was not talking about the DoV caution.  Our resolution on that issue is 
that there will be a general discussion in Ch.2 -- pro/con of DoV, caution 
about excess variability, etc -- and there will be a limited mention and 
back reference to Ch.2 in each GL representing a DoV.

Here is the original full proposal:

>LC-100: don't discourage extensibility.
>The position of the QA framework WG, that extensions should not be 
>allowed, is quite clear.  This doesn't accommodate those working on specs 
>that clearly demand public extensibility.  The document should describe 
>conformance not discourage extensibility.
>Discussion:  The SpecGL includes several cautions regarding the affect of 
>extensions (and other DoV) on interoperability.  Perhaps we go overboard.
>Proposal: Tone it down, in GL9, there are 2 places in GL9 explanation with 
>cautions; also include something about the usefulness of allowing 
>extensibility.  Make the last paragraph the beginning. (See also LC29.5 below.)
>The new Concept chapter will have a DoV caution and we agreed(?) that each 
>DoV would have a simple caution statement.

I was reading this as:  tone down the overall negativity toward 
extensibility, and specifically the extra cautions on extensions in GL9, 
and just go with the generic Ch.2 and simple per-GL statement about 
variability.  (I see now that it is a little ambiguous how to read it, but 
let's continue...)

With that, I disagree.

The statement, "each DoV would have a simple caution statement" seems to 
imply removing the extensibility cautions.  What we agreed did not carry 
the implication to remove the extra discussion from GL9.  GL9 wasn't even 
mentioned.   We were talking about *restoring* the per-GL DoV caveat, which 
was in earlier drafts, was part of the resolution of an earlier issue, was 
the subject of a current issue, and which disappeared without WG discussion.

Bottom line.  Keep the extra cautions about extensibility.  I don't mind if 
it is balanced with some discussion of a WG's perceived value of 
extensibility (**).  But as I have said before, the interoperability 
downside doesn't go away just because someone thinks their spec must have 
public extensibility.  At best, the risk-benefit ratio changes.

-Lofton.

** p.s.  As noted in the proposal text above, there is some simple 
discussion already, of why people use extensions (last pgph of GL9).



>10:54 AM 4/28/2003 -0600, Lofton Henderson wrote:
>>[switching thread to www-qa....]
>>
>>At 10:59 AM 4/28/03 -0400, Mark Skall wrote:
>>
>>
>>
>>>>>The new Concept chapter will have a DoV caution and we agreed(?) that 
>>>>>each DoV would have a simple caution statement.
>>>>
>>>>I have made an alternate proposal, which has been linked from the issue 
>>>>list for some time:
>>>>
>>>>http://lists.w3.org/Archives/Public/www-qa-wg/2003Apr/0026.html
>>>>
>>>>I disagree that we should "tone it down" -- extensibility is #1 on my 
>>>>interoperability list of evils.
>>>
>>>
>>>Extensibility does not equal DOV.  DOV has to do with 
>>>variability.  Every technique for variability does not "extend" the 
>>>standard.  Subsetting, for example, does not extend.  rather it 
>>>organizes things differently
>>
>>Hmmm, I'm not quite sure that I understand your point.  Extensibility is 
>>one of the (current) 8 DoV, and has been such since June 2002.  From "4. 
>>Definitions":
>>
>>dimensions of variability
>>the ways in which different products that are conformant to a 
>>specification may vary among themselves. In this Specification Guidelines 
>>document, the dimensions of variability are used to help organize, 
>>classify and assess the conformance characteristics of W3C specifications
>>
>>Extensibility certainly fits as one of the ways in which conformant 
>>products may vary amongst themselves.
>>
>>My original point was that, while acknowledging the reasons for which 
>>specs allow extensibility, we should also keep strong caveats about the 
>>consequences.  In my (direct) experience, there have been few cases 
>>(none?) in which there is not some interoperability downside, regardless 
>>of how well justified the use of extensibility might be.  If someone were 
>>to offer an example (no interop downside), it would be interesting to include.
>>
>>In the balance, it may indeed be that the benefit of extensibility 
>>exceeds the cost.
>>
>>
>>
>>-Lofton.
>
>****************************************************************
>Mark Skall
>Chief, Software Diagnostics and Conformance Testing Division
>Information Technology Laboratory
>National Institute of Standards and Technology (NIST)
>100 Bureau Drive, Stop 8970
>Gaithersburg, MD 20899-8970
>
>Voice: 301-975-3262
>Fax:   301-590-9174
>Email: skall@nist.gov
>****************************************************************
>

Received on Monday, 28 April 2003 15:08:24 UTC