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

changes are fine with me

At 05:01 PM 2/16/2005 -0500, Karl Dubost wrote:
>New proposed text after Richard Kennedy Suggestions:
>http://www.w3.org/mid/8dfb6f9190b9bb7924786ea04c93659c@boeing.com
>
>
>====================================
>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
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=1089)
>
>
>proposed Text
>
>Abstract of Changes:
>title:
>      “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.
>
>Related
>         •       D3. Define error handling for unknown extensions
>
>Techniques
>         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
>
>Examples
>
>In Mathematical Markup Language (MathML) Version 2.0 (Second Edition) 
>[MATHML20],  MathML2.0 section 7.2.1.2 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