RE: [tag] What "backward-compatibility" means - UPDATE

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

[I think I am dyslexic over up- and down- and forward- and backward- .  Let
me try again here.] 


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 three flavors of compatibility among implementations of
different specification versions:

1. Up-level compatibility.  Artifacts and processes that conform to the
older version of the specification are conformant for the newer version with
identical semantics.

2. Down-level compatibility.  Any additional constructs and semantics
provided in the later version is accomplished in a manner by which a
processor designed for earlier versions of the specification can
differentiate between an ill-formed or invalid occurrence and an
unrecognized/unsupported feature/extension.

3. Graceful down-level/extension degradation.  There is a means, established
in the earlier version, by which a producer of later-version/extended
artifacts can inform implementations of earlier versions how to work around
features not recognized according to earlier versions of the specification
and/or extensions.

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,

<http://docs.oasis-open.org/templates/namespace.html> in particular.

Whether or not we use the term "backward-compatibility", we should be clear
what can be counted on with regard to (1-2) in the maintenance of
TAG-defined namespaces.  Case (3) can involve namespaces but it also
requires explicit introduction of elements and tags and probably additional
principles for namespace maintenance.  I don't think it is particularly apt
for TAML the way it is for office-productivity documents of various kinds.

I ignored the case of deprecation of features from earlier versions,
although it can be cause for a new namespaces that omits the deprecated
features.

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

[ ... ]


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php