Re: Conformance and Deprecated Features

With travel and other stuff, I was out of this loop for a while.  I don't 
see strong closure yet, although maybe some convergence.  It's an important 
issue, and we will have to find a resolution in the context of producing 
the "Framework:  Specification Guidelines".  Unless there are objections, 
I'll put it into the QAWG's issue list.

Some responses on particular points in-line (to several different messages)...

At 11:39 AM 1/29/02 -0800, Rob Lanphier wrote:
>[...]
>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's view of "deprecated" matches my own.  But that's not the main point I 
want to make.  After reading the entire mail thread, I don't think this 
definition is universally agreed.  The key points moving forward are:  we 
should have consensus definitions of the two terms (hey, Glossary guys?); 
and, if there are indeed two distinct concepts, both need to be 
addressed.  They need to be addressed in the conformance statements of 
specifications of the WGs (where they are applicable), and they need to be 
addressed by QAWG in its "Spec Guidelines".

Which brings me to David's comment...

At 11:31 PM 1/29/02 -0500, david_marston@us.ibm.com wrote:
>This is beginning to look more like an issue for theOASIS TC on
>Conformance. In some cases, deprecated features can be handled as
>discretionary items, or under levels or profiles. At the time that a WG
>intends to deprecate a feature, they must follow some guidelines, but
>the guidelines would depend on the nature of the Recommendation.
>[...cut detail...]

It is also within the scope of the "Spec Guidelines" part of the Framework 
documents, I think.  It could be inferred but is not directly spelled out 
in [1].  There is considerable overlap in the concepts being tackled by 
OASIS Conformance TC and the scope of "Spec Guidelines", and there is 
considerable overlap in personnel as well.  In fact, the current TC 
document, "Conformance Requirements for Specifications", has been submitted 
to the QAWG as a contribution.

David's other point is well taken also -- we will not find a "one size fits 
all" guideline that will work for all WGs.  This thread started with a 
question from Karl [2] in the specific context of MathML.  It quickly got 
into generalities before coming back on the idea that proper specification 
(Rec) treatment of deprecated features depends, as David said, "on the 
nature of the Recommendation".

Coming back to Rob's comment at the (current) end of the thread,

At 11:04 AM 1/30/02 -0800, you wrote:
>This is a good point.  It seems there's a couple things that make sense:
>
>1.  QA-WG comes up with the menu of recommendations in the style from your
>previous mail, picking a preferred, but not mandated option. '
>
>2.  It may be worth raising this issue with the W3C TAG

The "previous email" is the one of David's [3] that contains a strawman 
menu of options (which detail I excised above).  The challenge in drafting 
"Spec Guidelines", and its accompanying "Spec Examples and Techniques", 
will be to abstract some widely applicable Guideline-Checkpoints for the 
former, and give some good, varied "how to" examples in the latter.

Regards,
-Lofton.

[1] http://www.w3.org/TR/2002/WD-qaframe-intro-20020201/#DocumentsRoadmap
[2] http://lists.w3.org/Archives/Public/www-qa/2002Jan/0052.html
[3] http://lists.w3.org/Archives/Public/www-qa/2002Jan/0064.html

Received on Thursday, 7 February 2002 19:28:10 UTC