Modifications to SpecGL checkpoint 8.3

From the December 20 draft:
>Checkpoint 8.3. Indicate any constraints on the number of
>choices/options that can be implemented [Priority 2]
>
>To fulfill this checkpoint, a specification MUST indicate whether
>zero, exactly one, or a multiple of choices/options are allowed to
>be implemented. It is not applicable for specifications that don't
>use discretionary items or for implementation dependent values among
>them.
>
>Examples of constraints include mandating that an implementation
>implement only one choice, implement every choice, or be
>allowed to implement none of the choices.

======== Proposed new version =======================
Checkpoint 8.3. Indicate any constraints on the number of
choices/options that can be implemented [Priority 2]

To fulfill this checkpoint, a specification MUST indicate, for each
discretionary item, whether zero, exactly one, or several
choices/options are allowed to be implemented. If the allowable
number is dependent on other dimensions of variability, the
dependencies MUST be stated. It is not applicable for specifications
that don't use discretionary items.

Rationale: the test framework can provide a tailoring mechanism so
that each implementation is tested with a set of tests tailored to
the choices made by the implementer. The tailoring mechanism for
choose-exactly-one items will not be the same as the tailoring
mechanism for choose-one-or-more items. The tailoring mechanism
needs to accommodate modules, profiles, and levels, when they are
used, which may affect the range of choices on some discretionary
items (and may drop the the range to zero in some situations).

Examples of constraints include mandating that an implementation
implement only one choice, implement every choice (allow the user to
choose), be allowed to implement none of the choices, or be required
to implement one specified value and as many additional values as
they wish from an open-ended list. An example of a constraint being
dependent on another dimension of variability is a rule that there
must be exactly one instance of the item for each profile that is
supported.
================================================================

NOTE: I don't know why the previous version said:
"It [This Ckpt 8.3] is not applicable ... for implementation
dependent values among them."
As far as I can tell, it *is* applicable. In any case where
handling of some feature is implementation-dependent, we would
want the spec to be explicit about whether the implementation
must implement one method and state it, or could make a choice
available to users. Even those implementation-dependent items that
are measured on a "continuous" rather than "discrete" scale, for
practical purposes, could have a boundary value. Example: while
an XSLT processor may be memory-constrained to any extent the
implementer desires, implementers are warned that failure to
support stylesheets of at least 10K characters in size will lead
to failing various tests in the suite on the basis of size alone.
By the way, I think that a statement like this satisfies the
checkpoint by correctly stating there are no constraints: "The
order of detection of dynamic errors is implementation-dependent
and so the first error message issued may vary between
implementations." Do we agree that saying that the results are
implementation-dependent with no constraining verbiage implies
that there are no quantifiable constraints?
.................David Marston

Received on Wednesday, 22 January 2003 17:14:33 UTC