[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on UBL-NDR 2 Versioning
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]