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

Dave
Thanks for your thoughts.  Although I need to read this more carefully, you 
present some good ideas.  One of the problems I have had in formulating the 
Guidelines 2-8, is that they are not discrete, but are interwoven.  A 
reader basically need to read them all and combine pieces of them.  I think 
you may be on to something by your list of permissible variations.

I would welcome any attempt at drafting text along with suggestions for 
rearranging what is there.

lynne

At 11:32 AM 4/18/02, David Marston/Cambridge/IBM wrote:
>I hope that I'll have time tonight to expand my previous verbiage about
>the nature of the spec (content, protocol, API, etc.) and the "classes
>of product" applicable to each, leading to a clearer Guideline 3 of the
>Spec Guidelines.
>
>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 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. 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.
>
>(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