I reviewed the UBL Naming rules, located at http://www.oasis-open.org/committees/download.php/9236/cd-UBL-NDR-1.0.pdf. As requested, I ent a comment via the form linked from UBL TC page. I thought that subscribers might be interested in my review, but the comment hasn't shown up in their archive yet. To be honest, I don't expect them to do anything with the comments. They've historically shown that they don't believe in decentralized extension, as that's they way the rules have been for quite some time. But you can't expect good things to happen unless you try...
I have a broad concern that the UBL Naming rules do not allow compatible evolution of the UBL components. In a distributed system, such as the Web and Web services, it is regularly not possible nor necessary to force all parties to upgrade their software at the same time. There are a variety of strategies that can be used to ensure that a compatible distributed evolution, that is evolution by only 1 side, is possible. These issues are expanded upon further in the W3C TAG finding on extensibility and versioning [1], an xml.com article on versioning xml vocabularies[2], and an ongoing work on extending and versioning XML languages article [3].
A design that enables compatible evolution that makes use of XMLs namespace features and supports evolving schemas involves re-using namespace names for compatible, or minor, changes to the names. This enables namespace aware software to not break whenever a compatible change is done. Should precise identification of the version of a vocabulary be required, a version attribute that specifies a minor version can be used. Further, UBL does not enable any extensibility as it does not specify any rules for allowing extensible content models and particularly XML Schemas wildcard facility and the Must Ignore Unknowns rule. It seems that delivery of the Universal Business Language would require 3rd party extensibility, and history has shown that existing formats (like EDI) regularly have extensibility shoe-horned in.
The concepts that UBL naming rules should specify are:
1. The addition of Must Ignore Unknown rule, which specifies that consumers of instances that do not recognize content must ignore it and not fault. This enables forward compatible evolution.
2. NMS2 rule should say Every UBL-defined or -used schema set MUST have a unique namespace name for incompatible versions. The corollary is that compatible versions should use the same namespace name. Minor nit, namespace names is a better term than namespace.
3. VER5 rule should say For UBL Minor Version changes, the
4. If necessary, the VER rules can add that a version attribute can be used to specify a minor version of a namespace.
5. The addition of requiring Extensibility in the UBL schemas using Schemas wildcards. There are a couple of schema designs that can enable this.
6. Provide a mechanism for 3rd parties to indicate their changes are required, ie incompatible.
These rules, in combination, enable compatible and loosely coupled evolution of the UBL data formats.
[1] http://www.xml.com/pub/a/2003/12/03/versioning.html
[2] http://www.w3.org/2001/tag/doc/versioning
[3] http://www.pacificspirit.com/Authoring/Compatibility/ExtendingAndVersioningXMLLanguages.html
