Re: Conformance and Deprecated Features

This is beginning to look more like an issue for theOASIS TC on
Conformance. In some cases, deprecated features can be handled as
discretionary items, or under levels or profiles. At the time that a WG
intends to deprecate a feature, they must follow some guidelines, but
the guidelines would depend on the nature of the Recommendation.

Other principles can assist in the establishment of a framework that
encourages compatibility:
1. XML itself and all XML vocabularies should use version numbers.
2. Where version numbers are not explicitly stated in the XML (like
   XPath, for example), the containing vocabulary (like XSLT) must
   specify version-number dependencies. (If your stylesheet says it's
   XSLT 1.0, then the XPath therein is XPath 1.0.)
3. The mechanisms that allow extensibility may also allow deprecation.
   (I believe that's what Mark wants to refine to: support of
   deprecated features is like supporting an extension.)
Note that point 3 tends to impose some restrictions on deprecation.
The choice to use or not use a deprecated feature is easy, but a
direct substitution is not.

To me, the discussion so far seems to indicate clearly that there
must be a standard of conformance that says the item under
evaluation does not propagate any deprecated material. For an XML
vocabulary, this simply means that an instance/document has none of
the deprecated elements, attributes, or whatever. For an active item
like a processor or server, it means that the item never outputs the
deprecated output. Again, this discussion seems to be more in line
with what OASIS is discussing. An item may also conform in another
profile if it contains or outputs deprecated material only when it
also includes a flag, designated in the standard, that encompasses an
explicit list of deprecated materials. (i.e., if my processor for
version 3.5 of the standard wants to emit now-deprecated material from
2.0, it must add the attribute xyz:deprecated="2.0" somewhere.)

Accepting deprecated material as an input is the heart of the
controversy. I suggest that we can at least limit the range of choices.
The analysis proceeds in two steps. First, the raw responses:
A. Fail to recognize deprecated input in any special way, treating it
   as a bad-input error.
B. Recognize the input of deprecated material, raise a special error
   indicating that it's deprecated.
C. Recognize the input of deprecated material, raise a warning, and
   use it as (originally) intended.
D. Recognize the input of deprecated material, and silently use it as
   (originally) intended.
E. Recognize the input of deprecated material, raise a warning, and
   ignore it.
F. Recognize the input of deprecated material, and silently
   ignore it.
Now step 2. A specification has a proper structure if it does exactly
one of these:
1. Require one of the A-F behaviors above. (A and F unlikely?)
2. Where versioning or namespaces make it feasible, require A when
   the flag is missing, and C or D when it's present, where "flag"
   means the item in the XML that indicates the potential for the
   deprecated material to be present.
3. Present a discretionary choice: input containing deprecated
   material may be handled one way (C-F, but only one) for those
   products that want to keep on running, or raise an error (A-B,
   preferably B) for those products that want to stop on errors.
4. Like 3, except that products that want to keep on running may
   allow a property to suppress warnings. In this scenario, it can
   be C as default and D with the property set, or E as default and
   F with the property set.
5. Exhibits one specific behavior (A-F) by default, but may be set to
   behave differently (B-F) by setting a property by API call or as
   an invocation option.
The requirement to pick exactly one of the choices 1-5 may be
weakened to one choice per major version (of the input), should the
input have been subject to numerous rounds of deprecation. Where a
property can be set, there may be variations to direct the message to
a particular destination.

Given the above, it becomes possible to test the conformance of an
item under the same mechanisms that cover other variations such as
discretionary choices or levels of conformance.
.................David Marston

Received on Tuesday, 29 January 2002 23:35:20 UTC