W3C home > Mailing lists > Public > www-qa-wg@w3.org > June 2004

Re: [SpecGL Draft] D4 Define how to handle each deprecated feature

From: Dominique HazaŽl-Massieux <dom@w3.org>
Date: Tue, 29 Jun 2004 11:26:00 +0200
To: Karl Dubost <karl@w3.org>
Cc: www-qa-wg@w3.org, Lynne Rosenthal <lynne.rosenthal@nist.gov>
Message-Id: <1088501159.1498.124.camel@stratustier>
Hi Karl,

Thanks for all the work! Comments embedded below.

Le lun 28/06/2004 ŗ 23:35, Karl Dubost a ťcrit :
> D.4 Deprecation
> Proposal:
> ---------------------------------------------
> Good Practice:
> 	Define how to handle each deprecated feature
> Meaning:
> 	A feature is usually defined when there is a better mechanism inside  
> the technology, or another technology that could be used, to achieve  
> the same effect (with often more possibilities).

I don't understand this defintion; could you propose another wording or
explain with more details what you mean?

>  It is important to  
> define the behavior of the different kind of products when they have to  
> read or produce deprecated features.

Either use "classes of products" or "implementations"; I think
introducing this new wording (kind of products) is going to be
Maybe using "consume" instead of "read" would better align with the
other sections as well.

>  The feature is likely to become  
> obsolete in the next version of the technology.

I don't think this is useful to add here.

> Care:
> 	It will help to establish transition/evolution strategies for the  
> users of the technology. It will help a consistent behavior when the  
> technology is implemented in different products and will be  
> particularly helpful when products can deal with different versions of  
> the technology.

Here is a proposed rewording:
Defining how deprecated features are handled allows to establish a
smoother transition for the users of the specified technology, and
ensure more consistency of the behavior across implementations. It is
also particularly important for implementations that needs to support
different versions of the specification.

>  For example, should a tool, able to read an old version  
> of the document, propose helping mechanism or conversion to the new  
> method which are preferred.

Here is another proposed rewording:
For instance, the specification may require that an implementation
supports both the features of the new and the old specifications, or
suggest a converting mechanism.

Dominique HazaŽl-Massieux - http://www.w3.org/People/Dom/

Received on Tuesday, 29 June 2004 05:27:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:36 UTC