[conformance] Backward compatibility and deprecation (was: Minutes of15 Feb 2002...)

[David Marston/Cambridge/IBM <david_marston@us.ibm.com>]

>Possibly:  for specification >1.0 the specification shall address upward
>compatibility and enumerate the behavior and conformance consequences for
>deprecated features.

I agree this is a SHALL. I think there must be a statement about
"backward" (not downward) compatibility, and there MAY be a statement
about "forward" (upward) compatibility if there is any provision in the
spec that is specifically there to provide for forward compatibility.
The compatibility verbiage seems to talk about an input as a whole
(e.g., entire XSLT stylesheet), while deprecation talks about details.

A classic example of a forward-compatibility provision would be to say
that in a particular stored-data file format, the version number of the
format shall always occupy the two bytes immediately after the byte
order mark, and no other data may ever be put there in any future
version of the file format. That can then dictate a compatibility
requirement on the player: any version of the player, even 1.0, must look
at the version number of the file and report a sensible error if it can't
play files of that version.

I think "deprecated" certainly has an implication that the feature must
not be propagated. Sometimes you can convert old notation to new and
clean it away; other times you may want to report it, as discussed at
length previously. The motivation could be either to allow a better use
of the same structure or notation after it has been obsoleted, or
simply to prevent an extreme complication (e.g., relative URIs for
namespaces) of little real-world benefit.

>Can you deprecate a MUST NOT assertion?

Of course. Sometimes, a MUST NOT is there to "reserve" a particular
format or protocol for an anticipated enhancement. Deprecating a
SHOULD is more interesting: I think it would be extremely rare to
"throw it wide open" by removing the SHOULD; more likely is that the
SHOULD tightens up. (Theoretical example: Lacking an encoding
directive, "SHOULD use an ISO-standard encoding" tightens up to
"SHOULD use a UTF encoding", which in some sense deprecates the 8859
family.)

>What are the pros/cons of backward compatibility?

Here's a big CON to consider: sometimes features are deprecated or just
plain removed because performance suffers too badly. If a spec is seen
to be under-adopted due to performance issues, its TC or WG may choose
to either adopt a new "lite" profile or a new version that has less in
it. While we often think of WWW standards, some can be used in intranet
situations where the IT Dept. can guarantee the lowest version of input
that will ever be encountered, and thus want a module that has good
performance because it doesn't carry all the baggage of the earlier
versions. While their inputs come from a closed and controlled world,
they would still like the benefits that come as a byproduct of
standards, such as a full suite of tools all suitably profiled to
handle the necessary range of versions, but no earlier.

Another interesting example is UDDI, where all the public servers are
supposed to be synchronized with respect to the data. It's probably
just as useful if they stay synchronized on the version of UDDI that
their software runs. If so, there is no need for the synchronization
piece to know how to synchronize with another server running a
different version.

Finally (for now), it's germane for me to quote my paper for the W3C
QA Workshop: "The next level of refinement in documentation standards for
the WGs is to recognize, and possibly impose, a classification scheme for
the documents themselves. In addition to the abstract-foundation type of
Recommendation (e.g., InfoSet), there are Recommendations that define a
vocabulary or syntax (MathML, Namespaces), ones that define a protocol
between two systems (XML Protocol), ones that specify behavior of a
processing program (XSLT), ones that define an API (DOM), and maybe other
classes such as a set of events." Perhaps a first go at classifying will
aid in discussion of deprecation, as well as profiles, levels, and
versions.
.................David Marston