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

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