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

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