Re: Conformance and Deprecated Features

Hi Loften and others,
I can understand being out of the loop for a while. I've been in a similar
state but for  different reasons.

As Rob is not a member of the WG and isn't on the list, he asked me to make
sure that this comes up for discussion in the WG and that it doesn't get
ignored or forgotten.

From reading your mail and your points below, I note that your already
suggesting that it go into the issues list, a suggestion I fully support. I
also agree that most of this discussion relates to the context of the
Specification Guidelines that's yet to be authored.

I agree with Rob's view of depreciated features, but from reading the mail
it seems that there isn't consensus here yet. It's clear that this issue
will need to be resolved and that some language relating to it will need to
be in the Specification Guidelines but what that is will need to be worked
out. My preference is to agree with Rob (that UserAgent x+1 must support
the depreciated features of x and that Authoring tools for version x+1
should not/must not implement depreciated features). But as David pointed
out, the QAWG may not have the ability to require all WGs to implement a
given level of backward compatibility.

Along that line, I think that Rob's suggestion to raise this issue with the
W3C TAG makes sense. This seems to me to be exactly the kind of issue that
the TAG was created to deal with.  To quote from their charter:
"W3C has created the TAG to document and build consensus around principles
of Web architecture and to interpret and clarify these principles when
necessary, to resolve issues involving general Web architecture brought to
the TAG,..."
This sure seems to be an issue that relates to Web architecture and that
needs some consensus and clarification. And we're the type of group that
should be bringing them these types of questions.

With a decision from TAG, we then would have the authority to make
requirements in the Specification Guidelines because it would be coming
from the Higher Authority (to use David's language).

From talking with Rob, apparently it's best to provide the TAG with a clear
list of already thought through options. Otherwise it is likely to get
bogged down in a mess of discussions and we may not see a decision from
them in a time frame that's useable for our group.

Anyway, that about sums it up.
Peter

At 4:26 PM -0800 2/7/02, Lofton Henderson wrote:
>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 Tuesday, 12 February 2002 15:20:43 UTC