conformance — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
RE: [conformance] Minutes of 15 Feb 2002, Telconference
Thanks for your comment - my comments are in line.
At 03:48 PM 2/15/02 -0500, Lynne Rosenthal wrote: [...] Can we make a generic statement? Possibly: for specification
>1.0 the specification shall address upward compatibility and enumerate the behavior and conformance consequences for deprecated features. It could also address the recognition (give an error, flag it, warning) of deprecated features.
Has anyone yet recorded a definition, exactly what we mean by
deprecated feature . Is it still legal but discouraged? Does it
pertain only to MUST features? Or also to SHOULD features and MAY
features? (Can you deprecate a MUST NOT assertion?)
[Lynne Rosenthal] No.
this wasn't specifically discussed. However, a definition is needed and
will be provided. the pertinence to MUST, SHOULD, MAY is a conformance
impliciation and not necessarily part of the definition.
The following
new issues resulted from discussion: New Issue : Should the
Conformance TC mandate how deprecated features are handled? New
Issue : Is backward compatibility important to all TCs?
New
Issue : Should backward compatibility be a requirement for all TCs and
stated as such in the Conformance Requirements Guideline. What are the
pros/cons of backward compatibility?
I think it would be useful to
make a precise definition of backward compatibility , particularly if it is
going to be used in an issue statement. Having missed the
teleconference, I'm not sure what is being discussed. Here are a couple
of possibilities that come to mind:
[Lynne
Rosenthal] Again, agree. A definition of what is meant by backward
compatiability would be good. I'm not sure how precise it
will be considering there may be different flavors depending on the type of
specification.
--
Considering versions
of the specification. A valid feature of version X of Specification ABC
remains a valid feature of version X+n, n=1,2,3... (and I'm being careless
with valid feature -- ignoring niceties like MUST, SHOULD, MAY, etc).
In other words, don't deprecate or withdraw features.
--
Considering
implementations. Some dictate about how authoring tools and/or user
agents that conform to version X+n of Specification ABC MUST, SHOULD, MAY, or
MUST NOT behave with respect to deprecated features of version X. The
earlier-used phrase upward compatibility could benefit from a consensus
definition also.
[Lynne Rosenthal] Thank you for the suggestions. This is a
good place to start.
We also know
that this will be a topic at the W3C QA F2F meeting next week and plan to
consider the outcome of that discussion in developing a section for this
document.
-lynne
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]