Re: SpecGL LC16 and 39: CP5.4 (o.ld 8.4) Discretionary items

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