Re: Conformance and Deprecated Features

SMIL 2.0 embodies a very different view of deprecated features.

SMIL 2.0 has the concept of different SMIL profiles (SMIL Language,
XHTML+SMIL, etc.), which are different permutations of modules (Timing,
Linking, Layout, etc.).  Handling of deprecated features is on a
per-profile basis.  SMIL 2.0 Language user agents are supposed to be
designed to be fully backwards compatible with SMIL 1.0 content.
Therefore, all deprecated features MUST be supported.

XHTML+SMIL is different, since there are no user agents that support
XHTML+(SMIL 1.0), and thus, not a lot of content in this format.  There
was no need to require compatibility with old content in this profile, so
the requirement is not there.

I think if the language is not clear in the specification, and that if a
policy must be stated, that user agents should have to support the
deprecated features.  This ensures that content (of potentially great
social or commercial importance) continues to be renderable, even after
the content author no longer can edit it (for which there can be many
reasons, death being one).

Rob

On Tue, 29 Jan 2002, Mark Skall wrote:

> 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 13:41:28 UTC