Re: [www-qa-wg] <none>

At 09:37 AM 12/2/2002 -0500, Mark Skall wrote:
>Some in-line responses to these points:
>
>At 09:17 PM 12/1/2002 -0700, Lofton Henderson wrote:
>
>>[...]
>>>Proposal:
>>>For SpecGL, specifically state in the Scope, the class of product that this
>>>document targets is xxxx.
>>
>>I agree that we should be more careful to define class of product (CoP) 
>>and category of SpecGL, in SpecGL.  I disagree with Mark's assertion that 
>>we necessarily need to add "specification" to the enumerated list(s).  It 
>>depends on how widely useful a "specification" CoP is.  Is SpecGL likely 
>>to be the only (Rec, or Note, or whatever) that addresses the 
>>"specification" CoP?  If so, then we should not add it to the enumerated 
>>list.  We should use the "...else define your CoP" variation of the 
>>requirement.
>
>
>Your assertion that we shouldn't include specifications as a class of 
>product argues that we shouldn't expect SpecGL to conform to itself.  If 
>there is even one use of this class, it should be included. If we don't 
>treat conforming specs as a class equal to the others, why should we 
>expect specs to conform?

Not true (that a class-of-one must be included in the enumerated list). 
Checkpoint 2.1 says:

"To fulfill this checkpoint, a specification:

     * MUST list the classes of product it addresses
     * SHOULD use the above enumerated classes names when they match those 
of the specification
     * MUST define and describe any product class that does not match the 
enumerated set"

Maybe you are misinterpreting what I said (or vice versa).  You said that 
we needed to add "specifications" to the CoP enumeration list in the 
verbiage of GL2.  CP2.1 says if your CoP isn't in the enumerated list, then 
you must define and describe your CoP (3rd bullet).

I am recommending that we do the 3rd bullet approach (define and describe 
SpecGL's CoP in SpecGL's Introduction), rather than add "specifications" to 
the enumerated CoP list of the verbiage of GL2.  Reason.  If SpecGL is the 
only W3C Recommendation that will use the "specifications" CoP (is it?  I 
don't know), then why bother to clutter up the enumerated list?  That is 
why we added the 3rd bullet -- we only want the list to cover generally 
used CoPs, not every unique CoP that we can think of.



>>>13.2 Distinguish normative and informative text. (David and Mark listed 
>>>this)
>>>SpecGL specifically identifies non-normative references, but otherwise it
>>>isn’t clear.  Is it sufficient to only label informative items and by
>>>default everything else is normative? Do we want editors to label all
>>>sections, explain in Scope what is or isn’t normative?
>>>Proposal: For CP, do we need to add anything here or cover this in ExTech?
>>
>>I think what we need is a better common understanding of what we mean by 
>>normative and informative.
>
>
>That's the whole point. We shouldn't need to have a common 
>understanding.  SpecGL should be precise on this point so that we all have 
>the exact same detailed understanding.

We are violently agreeing.  I should have finished my  sentence by adding, 
"..., and carefully documenting that common understanding in SpecGL."

>>[...]
>>>14.1 Provide test assertions (for SpecGL conformance to SpecGL)
>>>Issue 99: Scope of definition of test assertion.
>>>What are the test assertions for the SpecGL?  The CP or the ‘to
>>>fulfill…’?  Is it ‘derived from the spec’s requirements? Can they all be
>>>measures/tested? (e.t., 13.3). Test assertion defined as a statement of
>>>behavior, action or condition that can be measured or tested.  It is
>>>derived from the specification’s requirements.
>>>Issue 99: Does the definition preclude expressing a test assertion in a
>>>formal language without words and phrases rather than in sentences?  What
>>>is definition in Glossary?
>>>Is there a mapping between the spec and test assertion?
>>>Proposal:  ?
>>
>>We have clearly stated in Issue List resolutions that the CP statement is 
>>a "title" for the CP.  The normative requirements -- i.e., the test 
>>assertions -- are contained within the body of the CP verbiage.  SpecGL 
>>and OpsGL have isolated the test assertions into the "to fulfill" markup 
>>sections, using RFC2119 terminology.  Those are the test assertions of 
>>those two GL documents.
>
>
>It doesn't matter what we say in an issue resolution.

...except that it prescribes what we should and should not do in 
SpecGL.  I.e., I was saying that SpecGL should reflect those issue 
resolutions (I believe that it does, but not clearly enough).

>SpecGL conformance must stand alone.  We are asking people to conform to 
>SpecGL, not to our issue resolutions.   According to my reading of SpecGL, 
>those are not test assertions.

I disagree.  As I put the pieces ("hints") together, that is the conclusion 
that I draw.  It was the intention of the authors, apparently (see 
ViewSource, the class="TA" attributes on those sections).  I agree with you 
that -- if these are the test assertions -- it should be unambiguously 
stated that they are the test assertions (although you seem to disagree 
that they are the TAs).

-Lofton.

Received on Monday, 2 December 2002 10:27:57 UTC