- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Thu, 04 Sep 2003 18:45:43 -0400
- To: david_marston@us.ibm.com, www-qa-wg@w3.org
Thank you David for taking the time to review and comment. My problem is that the concept of "separate rather than consolidated" is not clear to me and I believe that other people will also have trouble understanding it. Am I in the minority? Is this a commonly used concept? Is there another way to say what you are saying? Additionally, I my preference is for short rationales and ones that don't use RFC keywords - my belief is that if a rationale contains MUST/SHOULD/etc, then that statement should really be in the ConfReq, not the rationale. It bothers me that we are having so much trouble explaining what this CP is about. I think David comes the closest, but I don't like having a CP that takes so much explanation to understand it. lynne At 04:04 PM 9/4/2003 -0400, david_marston@us.ibm.com wrote: >I'll start by offering Choice 4. > >Checkpoint 5.4. Promote consistency across multiple discretionary items. > >Conformance requirements: the specification MUST indicate the rationale >for discretionary items being separate rather than consolidated. This >requirement is not applicable for specifications that do not have >discretionary items, or have only one discretionary item. > >Rationale: the use cases begin the process of setting expectations of >how implementations will be used. When further refined, the use cases >set expectations for variation or flexibility of implementations. Any >variability that is too detailed for the use cases is probably of low >value to the user, but it hurts interoperability. (See [link to excess >DoV paragraph].) When individual details are subject to discretion but >can be summarized as a policy-level decision, the specification MUST >present one named discretionary item for the policy OR present a >justification for dividing the item into smaller items. When one item >affects more than one feature, the specification of each such feature >SHOULD refer to the discretionary item by name and link to the place >where the item is explained generally. > >When a rationale exists for dividing a discretionary item that could be >consolidated, the rationale MUST cite benefits to the user and/or an >existing division over which the Working Group has no control. It may >present other reasons as well. Also, the related items should be >consistent in their range of options and their use of terminology. >(Consistent terminology is required to satisfy Checkpoint 13.3[link].) > >Specifications SHOULD propagate rules for consistent terminology about >discretionary items onto the implementations, especially when an >implementation could offer choices to the user. Where an implementation >may exercise allowed discretion by adapting to the environment in which >it is run, specifications SHOULD encourage the implementation and any >associated documentation to use the specification's terminology. >================================ > >If you followed Lynne's citation, you know that I supplemented this >proposal with some suggestions that put other topics (that some people >thought this CP was about) into other CPs. > >Yes, this choice has more of a focused impact than Choice 1. I see >Choice 1 as essentially permissive because a spec might satisfy it by >providing a rationale for the existence of a discretionary item rather >than a rationale for why the particular item is separate. >..................David Marston
Received on Thursday, 4 September 2003 18:46:24 UTC