Re: Conformance and Deprecated Features

Let's remember the original question: "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?"  You've given a reason why, in one type of 
specification, one type of implementation (user agents), should be 
implemented.   However, in your example, another type of implementation, 
(content developers), should not implement the deprecated features.  How 
about API standards?  In those standards, the distinction between these two 
types of implementations don't exist.  Would you still advocate 
implementing deprecated features there?  The cleanest and most consistent 
approach is to not require an implementation of something which (in your 
own words) "was probably a bad idea."

I think, at this point, we've probably agreed to disagree.

Mark



At 11:39 AM 1/29/02 -0800, Rob Lanphier wrote:
>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
> > ****************************************************************
> >
> >

****************************************************************
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 16:33:52 UTC