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

Here are some comments/proposals for the category/class issues group...

At 08:26 PM 4/12/03 -0400, Lynne Rosenthal wrote:
>[...]
>GL 2: CATEGORY/CLASS (#8, 11, 46, 48, 61, 73.3, 93, 94, [1])
>(#8  editorial, huh??)

It seems unrelated to the category/class issues.  Issues Editor malfunction.


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

2.) Add "specification category" and "class of product" to sec.4, 
Definitions, and link occurrences in the text of GL2 and its CPs.

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

4.) Fine tune the wording, and possibly the terms themselves in the lists, 
to resolve #46 confusions.

These take care of 11, 48 (below), 46 (except "sub-list" suggestion), 93 
(except TOC suggestion).

Hmmm... maybe the bulk of this SC/CoP discussion could be moved as 
subsections into a new Chapter 2, "Concepts", which could also contain the 
current 1.8 DoV section?  Then minimize the verbiage here in GL2, and 
heavily back link to the Concepts subsections and the Definitions?


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

I'm not sure that I see the beef here.  These lists enumerate a number of 
the most common specification categories and classes of product.  We do not 
pretend that they are exhaustive.  If your SC or CoP matches, then use the 
term in the list.  If no term in the list is an appropriate match, then 
define it.  (Note -- the ConfReq structure of 2.3 could perhaps be closer 
to that of 2.1).  Originator says, "The language should reflect that it 
leaves an enormous loophole for spec authors to ignore the existing 
lists."  Aside from the fact that the assertion is debatable, I would not 
support adding something like "note the enormous loophole where you can 
avoid using the lists".

IMO, if we offer useful definitions and concepts, clearly explained, people 
will use them.  We can't possibly write this thing in such a way as to 
prevent devious and intentional circumvention.

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.


>If category and CoP are to be called out normatively, then they should 
>have status in the ToC (e.g., have ids and be targets for hyperlinks, 
>subheadings to identify them visually) (#93).  Do we add this to CP13.4 
>(navigation)?

I am reading JM's comment differently, which says verbatim:  "...these 
should have status in the TOC (the list of categories and the list of 
classes should both have ids, be targets for hyperlinks, and should have 
subheadings to identify them visually)."  He is saying that SpecGL should 
have a TOC entry for our two lists in GL2.  I don't think it pertains to 
CP13.4, which defines navigation requirements for specifications.


>Additions to the lists:
>-Add to the list of categories: guideline

Issue reference?

(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?  )

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


>CP2.3, first occurrence of ‘categories of objects’  not obvious to the 
>reader what this is. Link to the definition and use this term, e.g., Most 
>specifications can be classified into one of the following categories of 
>object…”(#48).

[See above, my first set of comments.]

>Enumerate all CoP is an unreasonable requirement (#73.3)

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?

-Lofton.

Received on Thursday, 17 April 2003 14:07:47 UTC