What "backward-compatibility" means

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

It occured to me that the use of backward-compatibility is not exactly clear
in the discussion about Namespace revisions and what doesn't require change
of the namespace.

I think there are two kinds of compatibility among implementations of
different specification versions:

1. Up-level compatibility.  What a conformant older version has/does is
accepted with precisely the same interpretation by what newer-version
conformant entities have/do.

2. Down-level compatibility.  The same constructs for which there is
up-level compatibility have no additions that would have them appear
non-conformant to/in an older version.

3. Graceful higher-level extensions.  When there are extensions that are not
recognized in the lower-level specification/implementation, there is a
graceful means for restricted down-level interpretation that should be (not
shall be) good enough.

I think what is meant by backward-compatibility is case (1), above.  It
seems to be the only one that makes sense in the usages I have found so far.

Whether or not we use the term "backward-compatibility", we should be clear
what we can be counted on for all three situations with regard to namespace
components and their semantics.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/tag/200911/msg00036.html
Sent: Saturday, November 14, 2009 09:08
To: stephen.green@documentengineeringservices.com
Cc: 'TAG TC List'
Subject: [tag] Namespace versioning and backward-forward-compatibility
issues

I know of no architectural principle that suggests a restriction of an
allowed, conformant case to a narrower case qualifies as a
compatibility-preserving change.  That is generally regarded as a breaking
change since potentially-implemented cases will now be (1) invalid or (2)
mistakenly interpreted as conforming to the new restriction when that is not
the semantics that was intended by the previous conformant use.

[ ... ]

The boilerplate example of what constitutes preservation of
backwards-compatible changes is a bit mystifying to me.  I do not know how
to interpret the "wildcard" mention.  In any case, we should say what
constitutes backwards-compatible change for us or be willing for the default
statement to be made for us.

[ ... ]