Re: Conformance and Deprecated Features

At 10:42 AM 1/29/02 -0800, Rob Lanphier wrote:
>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.


In a generic sense, in order to support full backwards compatibility, the 
implementer would have to implement all features of previous 
versions.  Many standards do not have the concept of deprecated 
features.  We don't ask implementers, in general, to go back and implement 
all features from previous versions; why do we do that in the case of 
deprecated features?  I think we need to be consistent when we set policy.


>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.

Again, it's not consistent to require this for standards with deprecated 
features when we don't require this, in general.  Deprecated features have 
been deprecated for a reason.  I don't believe we should continue to 
support features that were proactively withdrawn.


>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
> > ****************************************************************
> >
> >

****************************************************************
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 14:24:44 UTC