Re: Conformance and Deprecated Features

On Tue, 29 Jan 2002, Mark Skall wrote:
> 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.

Generally, we *do* ask implementors to go back and implement all features
of a language that they claim the MIME type for (or at least, we should).
That's the key.  If you claim the MIME type, you MUST support all of the
required features of that MIME type, or else not claim it.  Otherwise,
documents retroactively get broken.

Working groups that want to make a break from the past have the option of
defining a new MIME type, but that working group is on a downright stupid
power trip to think that they have the power to retroactively declare a
document invalid.  The documents will continue to exist, and we aren't
doing implementors any favors by pretending that these aren't valid
documents anymore.


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

Deprecated != Withdrawn

Deprecated means "hey content authors: this was probably a bad idea, and
there are better ways of doing this.  Please don't continue to generate
content in this format".  Hopefully, deprecated features can fade into
obscurity, at which point, it becomes *safer* to withdraw them.  However,
it's always very dangerous to withdraw features, for reasons already
stated.

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:39:10 UTC