OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public Comment


Comment from: dorchard@bea.com

Hello,

I have 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 have sent a comment via the form linked from UBL TC page. 

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 XML’s 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 Schema’s 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 <name> MUST not change and the namespace name SHOULD not change.
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 Schema’s 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.

Cheers,
Dave Orchard

[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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]