Re: Conformance and Deprecated Features

Obviously, the ideal solution is for each specification to clearly state 
how it will handle deprecated features (as in MathML).

In the absence of this, it seems to me that deprecated features should be 
handled as if those features are not in the specification (assuming there 
is a fair and official process to determine the deprecated features and 
sufficient notice).  Once a feature becomes deprecated, it "disappears" 
from the spec.  Thus, an implementation can claim conformance if the 
feature is not implemented.

I think the more interesting question arises when the deprecated feature is 
implemented.  My view would be that an implemented deprecated feature 
becomes an extension, since something is being implemented that is not (no 
longer) in the specification.  Depending on what the spec says about 
extensions, this implementation may not be conforming unless it handles 
extensions according to the requirements in the specification.

Mark



At 08:28 AM 1/29/02 -0500, Karl Dubost wrote:
>Hi,
>
>Today, Max Froumentin [1], MathML[2] staff contact, asks me about 
>something interesting.
>
>What should be done to reach conformance when there are deprecated 
>features in a specification? Should the deprecated features be implemented 
>because they are in the specifications and the DTD? If the deprecated 
>features are not implemented can I still claim conformance?
>
>For the MathML specification, it's quite clear hopefully, but I guess it's 
>not for some specifications when it occurs.
>
>---------------------------
>In MathML 2.0, 7.2.1.2 Deprecated MathML 1.x Features [3]
>
>MathML 2.0 contains a number of MathML 1.x features which are now 
>deprecated. The following points define what it means for a feature to be 
>deprecated, and clarify the relation between deprecated features and 
>MathML 2.0 compliance.
>
>1.      In order to be MathML-output-compliant, authoring tools may not 
>generate MathML markup containing deprecated features.
>2.      In order to be MathML-input-compliant, rendering/reading tools 
>must support deprecated features if they are to be MathML 1.x compliant. 
>They do not have to support deprecated features to be considered MathML 
>2.0 compliant. However, all tools are encouraged to support the old forms 
>as much as possible.
>3.      In order to be MathML-roundtrip-compliant, a processor need only 
>preserve MathML equivalence on expressions containing no deprecated features.
>------------------------------
>
>[1] http://www.w3.org/People/maxf
>[2] http://www.w3.org/Math/
>[3] http://www.w3.org/TR/MathML2/chapter7.html#interf_deprec
>
>--
>Karl Dubost / W3C - Conformance Manager
>           http://www.w3.org/QA/
>
>      --- Be Strict To Be Cool! ---
>

****************************************************************
Mark Skall
Chief, Software Diagnostics and Conformance Testing Division
Information Technology Laboratory
National Institute of Standards and Technology (NIST)
100 Bureau Drive, Stop 8970
Gaithersburg, MD 20899-8970

Voice: 301-975-3262
Fax:   301-590-9174
Email: skall@nist.gov
****************************************************************

Received on Tuesday, 29 January 2002 10:01:30 UTC