W3C home > Mailing lists > Public > www-qa@w3.org > April 2003

Re: profiles/modules/levels

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 29 Apr 2003 18:57:54 -0600
Message-Id: <5.1.0.14.2.20030429183355.0282e2a0@terminal.rockynet.com>
To: Mark Skall <mark.skall@nist.gov>
Cc: www-qa@w3.org

At 05:51 PM 4/29/03 -0400, Mark Skall wrote:

>You're giving me a headache.  My responses are in-line.

"I don't know why I even bother."  (Basil Fawlty)

Cutting through copious amounts of misunderstanding, a couple of corrections...

>[...]
>>Andrew's original comment was this:  "At the moment we have specific 
>>checkpoints for p, m and l. But if someone wants to use a new type of Dov 
>>called 'personality' or whatever then SpecGL is silent."
>
>And these checkpoints apply specifically to how a target spec implements 
>SpecGL's requirements.  SpecGL is silent on "personality" because you 
>can't give guidance on what you don't yet know (silence can be golden).

Wrong!  Here is the whole point, and source of misunderstanding.

SpecGL knows the definition of DoV, i.e., the abstract concept.  Target 
spec authors know the definition of a DoV.  "...ways in which conformant 
implementations may vary."  SpecGL has enumerated the 8 most common 
DoV.  In fact, we can't think of any others, but Andrew worried that spec 
authors might.  E.g., "levules" (I like that better than 
'personality'.)  In 2004 (during the 18th Last Call of SpecGL?) Xblah WG 
invents a new way to partition the standard Xblah 1.0 functions for 
conformance. (Xblah 1.0 prohibits *functional* extensions, just to keep 
life simple). None of P/M/L can be used in place of Levules -- none of them 
fit the concept of Levules, without violating some fundamental of their own 
definition.

The Xblah WG determines (and QAWG agrees) that Levules fits the definition 
of a DoV.  Of course SpecGL could never have anticipated Levules.  But 
SpecGL could anticipate the invention some day of some new DoV.

So SpecGL could say:  "If it's not one of the big 8, and it fits the 
definition of a DoV, then your (target) specification MUST:  justify its 
usage (just as you would for one of the big 8); and define its relationship 
to the other (big-8) DoV".  (If it looks like a DoV, and smells like a DoV, 
then treat it like a DoV.)

Actually, I don't really care whether or not we do this in SpecGL.  But it 
is perfectly well defined, how to do it.


>>So, if "someone", i.e., a target specification, wanted to talk about its 
>>own conformance to SpecGL, then yes, the new DoV could be described as an 
>>extension to SpecGL.  However, SpecGL does not require that a target 
>>specification say anything about its own conformance to 
>>SpecGL.  Therefore the target specification in fact does not have to talk 
>>about new-DoV as a dimension of variability, or describe its relationship 
>>to other DoV, or any of the things that we *do* require target 
>>specifications do for DoV.
>
>Correct.  But it can (through a conforming extension) talk about it 
>specifically, rather than in general terms.  Also, I'm not sure why 
>someone would add this new DOV.

Neither am I.  But it could happen (which is what Andrew postulated.)

>The point is to give guidance about when and why to use P, M and L's.  I 
>think we should actually discourage other ways to do very similar things.

I agree.


>>Look at it another way.  If target specification uses 'profiles', then 
>>SpecGL requires that the target specification talk about it.  If target 
>>specification, in its conformance policy, defines a new way in which 
>>conformant target implementations of target specification may vary (i.e., 
>>a new dimension, "new-DoV"), then "SpecGL is silent".  Nothing in SpecGL 
>>requires that target specification discuss it.
>
>Yes, but how can we require the target spec to discuss "it" when "it" is 
>unknown.

See above.  The containing concept of "it" -- the well-defined *concept* of 
DoV -- is well known, even though we can't anticipate what "it" (a new DoV 
instance) will be.

-Lofton.
Received on Tuesday, 29 April 2003 20:55:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:59 GMT