Making SpecGL 7.3 more obvious

I have an action item to redraft Ck 7.3 to address issue LC-99. Here
is the attempt.

==================================================================
Checkpoint 7.3 If deprecation is used, define its relationships and
interaction with other dimensions of variability. [Priority 2]

Conformance requirements: the specification must indicate, for each
deprecated feature, either that it is independent of all other DoV or
else discuss the relationship between the feature and all other DoV.

Rationale: A deprecated feature could be a feature that was originally
present only in a particular class of product, module, level, etc. or
it could be a feature that was originally required of all
implementations. But an entire module, level, etc. could be deprecated.
Additionally, new discretionary choices could be spawned because a
feature has been deprecated. (Example: an implementation must either
accept content with the deprecated feature and process it as in the old
version, or offer a strict/lax option to control acceptance or
rejection end of such content.) As a further example, observe that the
MathML 1.x deprecated features discussed under Checkpoint 7.2 above
vary with respect to the class of product, because the deprecation
policy for producer products differs from the deprecation policy for
consumer products.
==================================================================

Additional comment about that last bit: Discussion of the interaction
between class of product (GL 2) and deprecated features (GL 7) is P1;
discussion of the interaction between deprecated features and *all*
DoV is P2. I don't have a problem with that.

General comment: when assessing the spec on interaction-among-DoV
checkpoints, or when writing a conformant spec, one should probably
take each instance of a DoV feature and ask how it is affected by any
of the other DoV that are used. That's part of how I arrived at the
ordering of the DoV. In the current case, I am saying that you assess
conformance to Ck 7.3 by taking each deprecated feature (not just the
presence of deprecated features in general) and asking:
Does this feature vary by class of product?
Does this feature's deprecation status interact with strict/lax policy,
   minimum requirements, backward-compatibility policy, etc. (GL 3)?
Does this feature vary by profile? Or, are some profiles deprecated?
Does this feature vary by module? Or, are some modules deprecated?
Does this feature vary by level? Or, are some levels deprecated?
Does this feature, by virtue of being deprecated, cause discretionary
   items to apply in a varying way? Could a discretionary item affect
   the feature's deprecation policy? Are new discretionaries spawned?
Does this feature affect extensions or an extensibility mechanism?

As always, deprecation presents an interesting wrinkle to the general
policy that versions are not a DoV. You can't have deprecation without
having more than one version, at least the way the W3C does things.
More broadly, you can't have a backward-compatibility policy (of which
the deprecation policy is a part) without having more than one version.
Nonetheless, the backward-compatibility policy only applies to the one
version being specified.
.................David Marston

Received on Thursday, 17 April 2003 16:47:17 UTC