Re: [conformance] Minutes of 15 Feb 2002, Telconference

[Lofton Henderson <lofton@rockynet.com>]

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?)  
>  
> 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:

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

Regards,
-Lofton.