W3C home > Mailing lists > Public > www-qa-wg@w3.org > February 2005

Re: [SpecGL] Section 2.2 Req A and 4.4 Req B.

From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
Date: Wed, 16 Feb 2005 19:44:25 -0500
Message-Id: <>
To: Karl Dubost <karl@w3.org>, "'www-qa-wg@w3.org'" <www-qa-wg@w3.org>

changes are fine with me

At 05:01 PM 2/16/2005 -0500, Karl Dubost wrote:
>New proposed text after Richard Kennedy Suggestions:
>2.2 What needs to conform
>2.2 Requirement A: Identify who or/and what will implement the specification.
>No need to change the prose if we accept the new definition of Class of 
>Product. See other mail today.
>(I have just change the or/and by resolution of ISSUE 1089
>proposed Text
>Abstract of Changes:
>      “Define how deprecated feature is handled by each class of product.”
>---> “Define how deprecated feature is handled.”
>Technique #1:
>         “Consider the effect of deprecation on all classes of products 
> that implement the specification (e.g., authoring tools, converter, user 
> agents).”
>---> “Consider the effect of deprecation on all products that implement the
>specification (e.g., authoring tools, converter, user agents).”
>4.4 Requirement B: Define how deprecated feature is handled.
>What does it mean?
>         By deprecating a feature, the Working Group indicates its desire 
> that the feature disappear from a future version of the specification. 
> The motivation may be to convert an old feature to a newer one or to 
> remove an old, dangerous, redundant or undesirable feature. Regardless of 
> the reason, it is important to define the affect this has on 
> implementations that may encounter this feature (e.g., consumer products 
> such as user agents or producer products such as authoring tools). Will 
> use of the deprecated feature be tolerated? Will it signal an error or a 
> warning? Typically, it is expected that a deprecated feature would not 
> affect a consumer (e.g. user agent), while a producer (e.g. authoring 
> tool) should issue a warning.
>Why care?
>         Defining how deprecated features are handled provides 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 instance, the specification may require that an implementation 
>supports both the features of the new and the old specifications, or 
>suggest a converting mechanism.
>         •       D3. Define error handling for unknown extensions
>         1.      Consider the effect of deprecation on all products that 
> implement the
>specification (e.g., authoring tools, converter, user agents).
>         2.      Define how it affects conformance
>In Mathematical Markup Language (MathML) Version 2.0 (Second Edition) 
>[MATHML20],  MathML2.0 section describes deprecated MathML 1.x 
>features in terms of MathML-output-conformant authoring tools, 
>MathML-input-conformant rendering/reading tools, and 
>MathML-roundtrip-conformant processors.
>HTML 4.01 [HTML401]:  In the conformance section of HTML 4.01, there is 
>the definition of deprecation and what user agents should do. The behavior 
>for other kind of products is not defined though.
>User agents should continue to support deprecated elements for reasons of 
>backward compatibility.
>Karl Dubost - http://www.w3.org/People/karl/
>W3C Conformance Manager
>*** Be Strict To Be Cool ***
Received on Thursday, 17 February 2005 00:45:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:34 UTC