Re: Should SpecGL be a spec?

Hmm.  Let me elaborate a bit..... I found the DoV discussion and its 
definition in the glossary somewhat difficult to understand (after several 
reads, I'm still not sure I  understand the definition).  I also agree with 
Alex that the SpecGL shouldn't read like a novel, thus I think there may be 
too much discussion of DoV.  I'm not saying that all of it should be 
removed, but I think it may be possible to cut it down and link to a white 
paper for the more detailed explanation.  You bring up an important point - 
the rationale for why DoV was 'invented' - that background is important and 
currently not available to those not involved in its 'creation'.  Again, 
the white paper would be a good place to capture this evolution information.

On another point - I'm somewhat bothered by the long explanations after 
many of the Guidelines  (e.g., GL2, GL3). I'm not saying this is bad 
information, only that it takes a bit of reading to get from the GL to the 
actual Ckpt  So, by the time I get to the Ckpt, I forgot the GL.  I don't 
have a recommendation for what to do about this.  I think that some of the 
problem will go away, when we extract the examples and put them in the 
ExTech document.

regards
lynne


At 08:00 PM 9/5/02, Lofton Henderson wrote:
>Lynne,
>
>At 03:45 PM 9/5/02 -0400, Lynne Rosenthal wrote:
>>I agree that some of the DoV discussion should be removed to another 
>>document.  One thought I had was that it could be put into a white 
>>paper.  Also, I think that as we revisit the SpecGL and as we develop its 
>>companion Examples and Techniques document, much of the explanation text 
>>and examples will be moved into the ExTech document.
>
>Question.  To clarify, by "some of the DoV discussion", do you 
>specifically mean SpecGL sec 1.5 [1]?  Or DoV discussion throughout?  (Or 
>do you mean what Alex is referring to his last paragraph below -- in order 
>to be self-conforming, how much does SpecGL need to address its own 
>DoV?  Are some of the enumerated DoV out-of-scope or n/a for a spec of 
>this type?)
>.
>I may be misunderstanding, but I'm not sure that I'd agree with moving the 
>DoV discussion.  We need to recall how we got here and why.
>
>In the 20020515 SpecGL WD [1], we had some vague statements about "flavors 
>of conformance", and it raised some discussion on this list that flavors 
>are evil (my paraphrase), and that SpecGL needs to discourage unnecessary 
>variations and flavors.  Before we could even argue the issue about the 
>latter, we needed to clarify what we meant by "flavors".
>
>DoV is how we are trying to organize the discussion of flavors -- the DoV 
>are the underpinnings of the flavors, if you will.  DoV are how we are 
>trying to highlight at least some of the key variables that should be 
>considered by specifications.  No, we won't hit all possible variables, 
>but I think we have captured a good bit of current W3C practice (as well 
>as ISO and other venues) in the current factorization.
>
>The usefulness of the DoV as an organizing concept for SpecGL is a key 
>issue that we are putting out for discussion with this working draft.
>
>-Lofton.
>
>[1] http://www.w3.org/TR/2002/WD-qaframe-spec-20020826/#b2b3b3d135
>[2] http://www.w3.org/TR/2002/WD-qaframe-spec-20020515/
>
>>At 02:10 PM 9/5/02, Alex Rousskov wrote:
>>
>>>On Thu, 5 Sep 2002, Lofton Henderson wrote:
>>>
>>> > I think we (QAWG and authors) agree completely, practice what we
>>> > preach.  We are aware that this (2nd published) WD falls short in a
>>> > number of ways.  You have pointed out a number of issues that fall
>>> > in this category.  SpecGL will certainly be conforming by Last Call
>>> > (anticipated:  1-Feb-2003) -- I can't imagine that we'd have the
>>> > nerve to put out a document with our names on it otherwise!
>>>
>>>Great!
>>>
>>> > As an exercise, one of the QAWG members will be measuring SpecGL
>>> > against itself.  This may happen against this draft, or against the
>>> > next published draft (anticipated:  1-nov-2002), or both.
>>>
>>>Measuring is good, though the result of such an exercise is already
>>>known: SpecGL is not SpecGL-compliant, at any level.  To become
>>>self-compliant, SpecGL would probably need to be restructured and
>>>rewritten in a major way (IMO). I would recommend that the exercise is
>>>given the highest (priority 1?) priority and that already-known core
>>>issues are discussed before they are written up in the revised spec.
>>>
>>>It should be possible, for example, to decide whether a huge DoV
>>>section is needed before [re]writing that section. Similarly, it
>>>should be possible to decide whether behavioral specs should be
>>>covered before spending time on an exact scope wording. Same for
>>>encouraging non-normative illustrations. Etc., etc.
>>>
>>>Thank you,
>>>
>>>Alex.
>>>
>>>--
>>>                             | HTTP performance - Web Polygraph benchmark
>>>www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
>>>                             | all of the above - PolyBox appliance