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

At 02:23 PM 10/25/02 -0400, David Marston/Cambridge/IBM wrote:
>[...]
>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.

Yes, that was the other thought that I had.  To be clear, right now I don't 
care strongly which of the two possibilities is its theme or role.  But I 
don't believe that its purpose is clear or that it hangs together tightly 
now -- it is a little mysterious to read.

For this revision (6 nov), what we can and should do is probably 
limited.  But we should take a close look at it later.

Speaking of later ... I'll get back to your other points ...

-Lofton.

> >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 18:35:00 UTC