- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Fri, 05 Sep 2003 14:26:52 -0400
- To: david_marston@us.ibm.com, www-qa-wg@w3.org
Thanks again David for your comments and the time to work on this. This is Much Better - by I may still be missing the point - If I understand this, then I don't think we should require that specifications provide such a rationale. I am now convinced that we should delete this checkpoint. My rationale is twofold: 1. this is not the original intent of the checkpoint (as I was the original author). The original intent was that I would get the same results, under the same conditions - e.g., if I choose an option, like 'large fonts', and view a page, then if I view another page or that same page (after refresh), I would get the same 'large fonts'. 2. If we agreed to change the focus of the checkpoint - then I don't agree with making a "specification indicate the rationale for them being separate rather than consolidated into a single discretionary item (one choice to make). At this time my recommendation is to delete this checkpoint and consider it for the next version of SpecGL - I think that we need more discussion, a better understanding, and perhaps, need to break this up into several checkpoint as well as provide specific examples of this. --Lynne At 10:42 AM 9/5/2003, david_marston@us.ibm.com wrote: >Lynne wrote: > >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? > >Okay, here's another try: >Checkpoint 5.4. Promote consistency across multiple discretionary items. > >Conformance requirements: when multiple discretionary items exist, the >specification MUST indicate the rationale for them being separate (which >allows independent choice on each) rather than consolidated into a single >discretionary item (one choice to make). 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. 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 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. > >================================ > >The trimmed part of the rationale was moved up into conformance >requirements. >..................David Marston
Received on Friday, 5 September 2003 14:27:20 UTC