Re: Spec guidelines: flavors/levels/modules/profiles/(etc.)

I haven't seen any push-back on this idea, that all of the dimensions of 
variation should be easily findable.  If there is no disagreement, then it 
should be incorporated into Spec Guidelines.  But we should clarify how to 
implement it...

At 11:32 AM 4/18/2002 -0400, David Marston/Cambridge/IBM wrote:
>[...]
>Nearly all the guidelines 2-8 beg for easy findability within the whole
>Recommendation document. Checkpoints 1.2 and 1.3, and maybe new ones,

Should we have:

a.) multiple checkpoints, by which I'm specifically thinking of a similar 
Checkpoint for each dimension (below) within each appropriate associated 
guideline?
b.) Or, 1 or 2 (or ...) general purpose "findability" checkpoints, for 
example under guideline 1?
c.) Or both?  (It doesn't hurt to have multiple inter-related checkpoints 
-- you see this in WAI standards, where they cross reference each other.)

I think #a or #c.  While we would like new specifications to have 
findability on *all* dimensions, we will also be measuring existing specs 
with the guidelines and checkpoints, and those may conform on some 
dimensions and not conform on others.  Non-conformance on a single 
dimension would cause failure of an all-in-one checkpoint.

>should make it clear that one should be able to take any Recommendation,
>start from its Table of Contents, and find a place where all permissible
>variations are enumerated in convenient lists. This navigation may pass
>through the conformance section if Ck 1.2 is followed.

The "how" of the navigation would seem to fit well into the scope of the 
future Spec Extech document, if the checkpoints are appropriately stated 
and explained.

>By "permissible
>variations" I mean:
>Flavors of Conformance (Gd 2)
>Modules (Gd 4)
>Profiles (Gd 4)
>Levels (Gd 5)
>Enumerated-choice discretionary items (Gd 6), ideally bundled
>Deliberately unspecified facets (Gd 6)
>Deprecated features (Gd 7)
>Extensions (Gd 8)
>Now that I have all these dimensions of variation explicitly written,
>I could see the value of a Priority 3 checkpoint that complexity is
>limited by not having more than two dimensions from the set {levels,
>modules, profiles} and maybe other checkpoints to encourage use of
>profiles or at least flavors for deprecation and bundles of
>discretionary items.

I like this idea, as it helps with the topic we were haggling over in the 
4/18 telcon -- what combinations of modules, profiles, levels should be 
allowed?

Do we agree to include such a checkpoint?  Under which guideline would it 
fit best?

-Lofton.


>(Clarification on "bundles of discretionary items": though there may
>be many individual discretionary choices sprinkled throughout the Rec,
>they often arise from broader ideas about how the specified software
>should operate. In the XSLT case, most discretionary items offer two
>choices, representing design philosophies to escalate an error or to
>continue processing. Thus, XSLT could have a paragraph addressing
>discretion (in its conformance section) that describes two bundles
>and presents a choice between two bundles.)
>
>To restate: when a software developer is reading a Rec, he/she wants
>to find, in a reliable and systematic way, all the dimensions of
>variation that are possible for a conforming product. The test lab
>wants to know all those dimensions from the Rec, plus know which
>choices were made by the developer for each product-under-test, thus
>motivating the proforma of Guideline 9.
>.................David Marston

Received on Sunday, 21 April 2002 18:38:58 UTC