OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

conformance message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: 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] | [Elist Home]


Powered by eList eXpress LLC