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

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 10:43:46 UTC