Re: category/class issues [was: Re: processing plan for SpecGL LC issues]

At 10:37 AM 4/18/03 +0200, Dominique Hazaël-Massieux wrote:
>Le jeu 17/04/2003 à 20:09, Lofton Henderson a écrit :
> > >Confusion as to difference between ‘class of product’ and 
> ‘category’ (#11,
> > >93).  Categories of objects” is still a poorly defined term. Suggest
> > >rename to: ‘category of specifications’ [1].  Confusing use of consumer
> > >and producer  used to distinguish classes or products and is also in the
> > >list. Suggest dividing the list into processor, consumer, or content;
> > >making the terminology in this area unique, so there is no ambiguity. 
> (#46)
> >
> > Proposals:
> >
> > 1.) Use the term "specification category" in place of "categories of
> > specification" and "categories of objects".  It contrasts better with
> > "class of product".
>
>My main issue here is that we 're trying just to re-label,

Clarification.  This is point 1 of a 4-point recommendation that 
collectively aims to resolve the several "I'm confused" comments about 
Categories and Classes.  See 
http://lists.w3.org/Archives/Public/www-qa-wg/2003Apr/0114.html

You cite #2 and #3 below, but not #4:  "4.) Fine tune the wording, and 
possibly the terms themselves in the lists,
to resolve #46 confusions."

>without
>trying to better define what we mean here. The verbiage starts with:
>
><<Categorizing the specification provides a basis for classifying the
>software that may be affected by the specification — and thus, provides
>the answer to "what needs to conform?">>
>
>We assert several things:
>- categorizing the spec helps categorizing the software (classes of
>products)
>- categorizing the spec provides the answer to what needs to conform
>
>While I agree with the 1st assertion, the 2nd seems backwards: one way
>to categorizing a spec is to answer the question "what needs to
>conform?" (but there are probably others).

I agree about the phrasing of #2.  It would be better (and accurate) if it 
said, "..and thus facilitates
answering the question, 'what needs to conform'".  If one clearly 
understands what kind of specification one is writing, it does contribute 
to understanding the conformance targets (classes of products).


>Then we speak about the "nature of the specification" (without saying
>what we mean by that), to finally give a list of categories, that we
>introduce 1st as a list of specification categories, and then (just
>after the list) as a list of things a specification can describe.
>
>All this mess is only presented for sake of CP 2.3:
>"the specification MUST identify in the Introductory section which of
>the categories of object are specified in the document as a whole."
>whose rationale is not even very convincing:
>" doing so helps keep the scope of the specification in focus, both for
>the reader, and for the author(s) who must define the classes of product
>and their conformance criteria"
>
>My take is that we should remove this checkpoint (priority 3, but I
>don't see how it improves the situation once you already have the list
>of classes of products),

I believe it contributes to getting an accurate and comprehensive list of 
classes of product.  For this reason, I like it and would prefer:  "clarify 
it or remove it" approach.

>and move the categories of spec discussion in
>ExTech as a way to help define the classes of products of a
>specification.

General comment.  We are saying about a lot of stuff, "move it to 
ExTech".  Are we keeping a list and verifying that this is actually happening?

2nd general comment.  IMO, we have removed too much in several 
places.  Some of the confusion and requests for clarification, I think, may 
trace back to removal of discussion of concepts, and "for examples".  While 
that is not the case here (yet), I want to think about whether we are about 
to remove something useful before giving up on it.


> > 2.) Add "specification category" and "class of product" to sec.4,
> > Definitions, and link occurrences in the text of GL2 and its CPs.
>
>Looks like a good idea to add the classes of products in the the
>Glossary, yes.
>
> > 3.) Clearly separate and label the subsections of GL2 verbiage which are
> > describing them.  (Note.  It might be problematic to use numbered 'h3'
> > subsections here -- both confusing structurally and problematic for XSLT
> > transform).
>
>That would be <h4>, not <h3>, and it shouldn't be a problem structurally
>nor xslt-wise.
>
> > [...]
>
> > >Checkpoints based on classes of products and categories are awkward
> > >because the use of the enumerated list is required, but only if
> > >applicable. Thus the use of the list is completely optional. (#94).
> >
> > [...]
> > Proposal.  Look carefully at our GL2 implementation of the 
> "non-exhaustive"
> > idea, make sure that it is clearly explained that these are some of the
> > more common, and you may need to define your own if one of them doesn't
> > appropriately fit your SC or CoP.
>
>Agreed. We have to note somewhere that it is an extensibility point of
>SpecGL,

I don't understand "extensibility point".

Why do we have to enumerate it as such?  We already have a general 
statement about extensibility in Chapter 3.  I don't see anything in GL9 
requiring "enumerate extensibility points".

>though (the extension mechanism being:
>- be sure it doesn't exist in specGl
>- define it clearly in your spec)
>
> > >Additions to the lists:
> > >-Add to the list of categories: guideline
> >
> > (I don't necessarily oppose the idea, but I don't understand it --
> > "guideline" is too vague.  E.g., SVG talks about "SVG Authoring
> > Guidelines", which could be written in the GL/CP style but contain
> > conformance requirements for SVG Generators -- technical.  Would this fall
> > into the same guideline category as WCAG, SpecGL, etc?  )
>
>I agree that "guideline" is too vague... A guideline is more a
>formatting technique for conformance requirements than a category of
>specification per se, I would think.
>
> > >-Add to the list of classes of products: technical reports [1], document
> > >and resources, or make document and resources examples of the ‘content’
> > >class. (#61)
> >
> > No strong opinion.  But I'm not sure that I understand these as 
> "..examples
> > of 'content' class".  As I understand 'content', they don't seem to fit.
>
>Me neither. I think it's a good idea to add "specifications" as a class
>of product (technical report is too "W3C-ish", document and resources
>lead to the confusion wrt content). "Specification" would refer to the
>way you specify some requirements rather than the format used to convey
>these requirements. Typically, the following specs have "specifications"
>as CoP:
>- Character model for the WWW
>- SpecGl
>- XML Accessibility GL (XAG)
>- Manual of Style (at least partly)
>
> > >Enumerate all CoP is an unreasonable requirement (#73.3)
>
>Note that 'all' doesn't appear in the ConfReq.
>
> > I don't mind removing "all", although I'm not sure that commentor is
> > understanding CoP the same way that I am (his example suggests to me more
> > just "P" than "CoP").  The important bit is in the ConfReq:  "MUST list 
> the
> > classes of product it addresses".  Btw, what exactly do we mean by "it
> > addresses".  Do we mean:  "...for which it addresses conformance
> > requirements" or "..for which it defines conformance requirements" or
> > something like that?
>
>I'm not sure to understand your distinction, here.

Are you asking about "P" versus "CoP", or about the clarification of 
"...addresses..."?

the First:  it sounds to me like the originator is concerned that we are 
asking to enumerate "all products", instead of "all classes of 
product".  His example seems to support that.

the Second:  I think "that it addresses" is imprecise.  I think what we 
mean is that a spec must list all classes of product for which it is going 
to make conformance specifications.  If this is indeed what we mean, then I 
was suggesting that we make the ConfReqs more precise.  For example, 
"...all classes of product for which it defines conformance 
requirements".  Or something like that.

-Lofton.

Received on Friday, 18 April 2003 10:21:53 UTC