Suggestion for drawing out comments on issues 69 and 70

I made suggestions about using the FPWD Spec Guidelines to elicit
comments about the complexity issue and the "what is a 'flavor' of
conformance" issue at [1]. Per your request, here is a bolder
proposal for the short term.This proposal has 4 sub-parts, each of
which can be accepted, altered, or rejected.

1. Introduce the multi-dimensional notion

Add a paragraph to section 1.4:
Theme 3: Multiple dimensions of variability can be accommodated in
the specification. The WG may determine that conformant products are
allowed to vary in one or more ways. This document provides the
following dimensions:
o flavors (Guideline n)
o product classes (Guideline n)
o profiles (Guideline n)
o modules (Guideline n)
o levels (Guideline n)
o discretionary choices (Guideline n)
o deprecation (Guideline n)
o extendability (Guideline n)
The above are not necessarily all orthogonal to one another;
possible associations are noted in the individual guidelines.

2. Issue a checkpoint about complexity

Checkpoint 1.5 Limit the number of dimensions of variability
[Priority 3]
Use of the variability tools in Guidelines M to N should be limited to
3 or fewer for a Version 1 specification and 4 or fewer for Version
2 and higher. (The extra dimension on later versions can be used for
deprecation, new technology, or to alleviate discord among
implementers.)

3. Clarify Guideline 3 to "Choose a conformance policy"

Adjust the verbiage of the guideline itself as above. Isolate some
key issues: What does the conformance rule say about a product that
does more than is specified? If two products make different choices,
can their interoperability be determined from their respective
conformance statements? What discretionary areas arise because the
WG chose not to venture into that area?

(BTW, my view of the "Conditional Conformance" portion of UAAG is
that it's really modules and levels.)

4. Reorganize the guidelines into a logical progression

Splitting the current Guideline 5 into separate ones for modules,
profiles, and levels, we then have 14 guidelines that can be
arranged from the general to the specific as follows. In other words,
most of the influence will flow down this list, and there are
relatively few instances where a point on this list depends on
determinations of what to do about higher-numbered (lower-level)
items.
(Numbers use old --> new notation.)
7 --> 1   Scope and use cases (often in Requirements Doc)
4 --> 2   Spec categories and product classes
5B --> 3  Profiles (think: hardware)
5A --> 4  Modules
Given the above strategic objectives, we have about enough to
characterize a conformance policy and (at least in later editions)
a deprecation plan.
3 --> 5   Conformance flavors or policy
9 --> 6   Deprecation policy
At this stage, we can consider the other dimensions of variability
that are dependent on the overall plan.
5C --> 7  Levels
8 --> 8   Discretionary items
10 --> 9  Extendability
The rest of the items are more tactical in nature, though still in
order from general to specific.
2 --> 10  Conformance clause
6 --> 11  Claims
11 --> 12 Proforma
1 --> 13  Document conventions
12 --> 14 Grammar

Notice that I am not proposing to catalog all the possible
dependencies among the dimensions of variability (or any other items)
at this time. If you want to have an example, I think levels are
the easiest:
levels are a direct product of the conformance policy;
different product classes or profiles may have their own levels;
if there are modules, each should be considered for levels;
levels could supersede or drive discretionary choices;
levels could supersede extensions;
deprecation probably cuts across levels, but it's a fuzzy area.
Maybe part of the above sees print this time, to illustrate how levels
are not entirely orthogonal to other aspects, but I think we're
looking for feedback at a higher level that could simplify away
some of the existing dimensions.
.................David Marston

Received on Tuesday, 11 June 2002 00:03:35 UTC