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

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, 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).

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), and move the categories of spec discussion in
ExTech as a way to help define the classes of products of a
specification.

> 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, 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.

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org