- From: Lofton Henderson <lofton@rockynet.com>
- Date: Fri, 25 Oct 2002 16:35:07 -0600
- To: David Marston/Cambridge/IBM <david_marston@us.ibm.com>, www-qa-wg@w3.org
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