Re: [ISSUE] Clear GP/Principle statements

At 03:46 PM 10/1/2004 -0400, Karl Dubost wrote:
>>[...]
>>Suggested rewording:
>>Define the normative terms in-line, and consolidate these definitions in
>>a glossary.
>
>here I think we loose a bit of the section issue. Do we want absolutely to 
>have to a glossary inside the specification or can it be outside of the 
>spec ala QA glossary. Depending on that the sentence can be slightly changed.

This issue has an extensive history in the QAWG Issues List, going back to 
the Tokyo meeting (and before).  That should be referenced and reviewed, 
before we re-argue it and arbitrarily choose a different resolution.

[...]

>>>ICS-017-GP: Subdivide the technology to foster implementation
>>"Create subdivisions of the technology when required by the variety of
>>implementations"
>
>Create technology subdivisions when needed for implementation diversity.
>
>Still not good.

In graphics standards, Profiles were originally called "Application 
Profiles".  It is diversity in application requirements (use cases, usage 
scenarios, etc) that drive profiles, not diversity in 
implementations.  (Diversity in implementations follows on from diversity 
in application requirements.)

[...]

>>>ICS-022-GP: Indicate any limitations or constraints
>>
>>"Indicate limitations and constraints of the optional features"; I think
>>it needs more work since one of the intent of the GP is to encourage
>>narrowing the optional features altogether.
>
>Limit the choices on optional features by defining all their limitations 
>and constraints.
>
>Sounds more positive:
>Optimize the choices on optional features by defining all their 
>limitations and constraints.

The meaning here seems to be straying pretty far from the original meaning 
of the Checkpoint in the CR text.  It might be useful to go back and look 
at that.

All for now,
-Lofton.

Received on Monday, 4 October 2004 13:10:45 UTC