Comments on UBL-NDR 2 Versioning

["Marc de Graauw" <marc@marcdegraauw.com>]

Some very late comments.

First of all, great work. I've used the UBL NDR in a non-UBL context, and
these are a set of important and coherent guidelines. Also IMO, 2 is a
significant improvement over 1 - see below. I've some comments on
versioning, which has been one of my favourite pastimes lately (I've also
blogged on some of the issues).

585-6 "The schema set is the versioned entity, all schema modules within
that package are of the same version, and each version has a unique
namespace."

... the same, or another minor version... At least, minor versions don't get
new namespaces anymore.

667-8 "In UBL, the major-version field must be changed in a release that
breaks compatibility with the previous release of that namespace."

The term 'compatibility' is not defined. It's very likely the spec uses it
in the sense of backward compatibility, where every UBL version n document
is a valid instance of an UBL version n+1 language definition, but since
this is a thorny issue, I suggest the meaning of 'compatibility' should be
defined. To make an example, making a required element optional is backward
compatible (v1: ab -> v2: ab?) since every v1 doc is valid in v2. This means
old senders can safely send old documents to both old an new consumers. The
reverse, making an optional element required ((v1: ab? -> v2: ab), is not
backward (but forward) compatible since every v2 doc is valid in v1. This
means new senders can safely send documents to both old an new receivers.
The sender-receiver assymetry makes forward compatibility as important as
backward (though probably less common). Therefore, I feel, in a
sender-receiver context, spelling out the meaning of compatibility is very
important. Implementers will need this to know whether it is safe to send or
accept a new minor version document.

702: "For UBL Minor version changes the namespace name MUST not change."

Very much appreciated. I work for (amongst others) the Dutch Criminal
Justice Chain, and am co-responsible for their versioning standards. We used
UBL-NDR 1 to craft our own vocabulary, but recently adopted the NDR 2
minor-release namespace rule. I believe it's essential, because it allows
the addition of new documents (along with needed new vocabulary items) in
the same namespace, a very common business case, which does not warrant nor
require a new namespace. At least, given my interpretation of
'compatibility', that's my conclusion of the impact of this rule...

723-4: "UBL Schema and schema module minor version changes MUST not break
semantic compatibility with prior versions.": In general, the versioning
rules give no room for post-release errata. If UBL 2 schemas were to contain
a single small, unfortunate but - alas - incompatible typo, would you
release UBL 3 as a consequence? This sort of scenario might be hard to
capture in rules, and that may not be wise either, but probably some
provision needs to be made.

727-8: "Every UBL Schema and schema module major version number MUST be a
sequentially assigned, incremental number greater than zero."

Q: Is this for drafts or OASIS standards? In other words, may standards skip
numbers for drafts which never make it?

Aside from versioning, I heartily agree with Juerg's comment
(http://lists.oasis-open.org/archives/ubl-comment/200610/msg00000.html):

"The vast majority of UBL NDR 2.0 rules equally apply in spirit to a
non-OASIS
context. We found the rules fall into one of these categories:
- Adopt a rule as-is" ... etc.

I'd kindly suggest an item for the NDR 3: separate the NDR from UBL-sec,
stating which rules are UBL-specific, and which ones are not, thus allowing
non-UBL vocabularies to claim conformance to the NDR. Their importance
transcends the reach of the UBL domains. In general, a conformance paragraph
would be welcome too, perhaps allowing conformance claims which allows to
state exceptions for local contexts. 

Regards,

Marc de Graauw
www.marcdegraauw.com