Re: GL6 "Conformance Policy (was: Re: SpecGL problems/issues for telcon 28 Oct)

LH>The verbiage of GL6 doesn't read too badly -- it leads me to believe
LH>that this is sort of an "umbrella" guideline over the other more
LH>specific ones.

It might also be the catch-all, which could affect your thinking on
some points.

>6.1: Specify any universal requirements for minimum functionality
LH>Aside about 6.1:  what are "universal requirements for minimum
functionality"?

I think this means: identify any "core" functionality that all
implementations must have. It's under GL 6 because it won't always be
a level (Level 1); it could be a module or it could be implementation
of only the latest spec without support for deprecated features.

LH>If they may vary in a way that is not one of our DoV, is there any
LH>place where we require that such a private dimension be documented?

This might be a role for Ck 6.4 (special terminology). I'd hope that
any variance can be portrayed as a module, if not one of the more
specific DoV mechanisms, so this remains a theoretical-only issue in
my view. (Extensions, deprecated-feature support, levels, and profiles
can be mapped to modules readily. Class of product is a little harder
to map. Mapping discretion is messy or trivial, depending on your
approach.)

The DoV were originally presented in a specific order that caused the
general conformance stuff (now GL 6) to fall into the middle. One way
to clarify this guideline would be to think about how it could move
toward the low-numbered end, as Lofton suggests with his 10,000-feet
remark. Can the overall planning process, as echoed in the SpecGL, be
arranged in this order?
1. Scope (i.e., why does the WG even exist?)
2. Class of product (what thing(s) will be specified?)
3. Conformance strategy (how to achieve interoperability)
4. Profiles (what subgroups exist in user base?)
...then on to other DoV
The above may push profiles down too far, if it has to take over the
"usage scenarios" role from GL 1. Thus, 3 and 4 may have to swap.
But if you take it as a goal to make the current GL 6 more about
scoping the interoperability (subservient to GL 1, scoping the
solution space), then you can move it up the abstraction scale and
say that you only know whether you have modules after you've scoped
the interoperability. (In contrast, I put deprecation, levels,
discretion, and extensions lower than the conformance policy GL
because they all were clearly subservient.) As previously noted,
you get past all 8 DoV before hitting GL 10, which addresses the
*expression* of the conformance strategy in the specs.

I hope that this view of the guidelines as dependencies (GL 1 being
the most independent) helps to clarify the role (and position) of
the "conformance policy" guideline.
.................David Marston

Received on Friday, 25 October 2002 14:30:05 UTC