Namespace versioning and backward-forward-compatibility issues

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

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 recommended approach at OASIS seems clear.  The TAML Namespace(s) URI
Versioning policy must be pre-established by the TAG TC per Namespace as
part of providing Namespace URI documentation and RDDL (see
<http://docs.oasis-open.org/templates/rddl.html>).  (Note that OASIS prefers
use of resolvable Namespace URIs in accordance with 
<http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingV0
8.html#NamespaceDesign>.)

In the boilerplate version (which may be the OASIS default), future
extension of a namespace may happen, at the declared-in-advance discretion
of the TC.  That means, to me, that down-level implementations will be
surprised unless the original standard stipulates the appropriate behavior
when unexpected namespace components and terms are encountered.  (My
preferred boilerplate would foreswear additions to an existing namespace for
exactly that reason and in order to distinguish between "mistakes" and
unrecognized extensions.)

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.

It is intriguing for me that the rule for namespace revision applies at the
Committee Draft level.  We don't have to make revisions at the TAML
working-draft level except from Committee Draft to Committee Draft where
there is a loss of backward compatibility as we define it for TAML in the
first Committee Draft.   

As well as I can tell, we are not talking directly about namespace extension
on this thread.  We are talking about extension of the allowed set of an
attribute value starting out restricted versus starting out loose and being
restricted later (although that might require a namespace change too).

Relaxing a restriction (that is, allowing more cases while not changing the
established cases) is preferable to the reverse.  This is not unlike the
case of extending a namespace by additions.

My preference, as must be reasonably clear on this thread, is (1) to handle
the extension case from the beginning, (2) never add to the list of
predefined unprefixed terms under the same namespace, and (3) specify the
conformant behavior for encounter of unrecognized extensions, whether
implementation-defined (and documented as a condition of conformance) or
implementation-dependent (and not required to be explicitly documented).

 - Dennis

PS: An interesting way to challenge these ideas and the alternatives is to
see how one could successfully introduce Test Assertions in the respective
cases.

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
Of Stephen Green
http://lists.oasis-open.org/archives/tag/200911/msg00031.html
Sent: Friday, November 13, 2009 13:19
To: dennis.hamilton@acm.org
Cc: TAG TC List
Subject: Re: [tag] Proposal: Providing Decentralized Extensiblity of
Enumerative-Attribute Values

>>> PS: There is an architectural principle that is vaguely applicable here.
>>> "It is always easier to relax a restriction in the future than there is
to
>>> impose a restriction that did not apply previously."  That has a lot of
>>> weight with me.

I have always taken the opposite view - and I'm open to correction here:
If you use normalized string then later decide to restrict it to qualified
name isn't that an acceptable change not requiring a new namespace?
I have always tended to think so. Am I wrong in that?

The principle seems to be, with schemas, that a tightened restriction is
fully in keeping with the previous version. Doesn't this comply with the
architectural principle we all follow of later profiles placing restrictions
not placed previously while not loosening restrictions which are enforced
by the previous version of the parent standard?

[ ... ]