W3C home > Mailing lists > Public > www-qa-wg@w3.org > September 2003

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

From: <david_marston@us.ibm.com>
Date: Thu, 4 Sep 2003 16:04:37 -0400
To: www-qa-wg@w3.org
Message-ID: <OF3C8B955A.713087B9-ON85256D97.006D4745@lotus.com>

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 16:05:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:34 UTC