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: Re: [ubl-comment] Public Comment


David,

this is a personal response, and it should not be construed as representing
in any form the views of the UBL TC, as I have not consulted with anybody
there and I am not part of the NDR comments review subgroup that will deal
with all comments regarding it (except, of course, in my thanking you
for taking the time to read the document and commenting on it; I'm pretty
sure I'm on solid ground), nor should it be interpreted in any way as a criticism
of the work that you and Norm have done on behalf of the TAG in this area.
I also don't intend to start a religious war, or one of those interminable
dialogues where you say x, I say y, you say x', I say y', etc. etc. ;)

The statement that the UBL Naming and Design Rules do not allow compatible
evolution is not quite correct. They do allow it, but in a manner that is
different from what you and Norm recommend. The main difference is perhaps
rooted on the fact that you deal with the broadest possible number of cases,
whereas we deal with one very particular one.

 From the very beginning of the activities of the NDR sub-committee we recognized
that the aim of the whole exercise is to enable people and processes to
produce business documents with the intention that they be legally binding.
It was therefore agreed, from a very early date and with no dissension, that
the use of wildcards in content models would not be permitted, as they render
validation worthless and of no more value than well-formedness checking in most
cases.

As an alternative to this (and by implication to the solution you recommend)
we elaborated a different one, based on XSD's extensibility mechanisms only,
and on type processing.

It would be silly for me to reproduce here the methodology, as it is laid out
in the Contextualization Guidelines that are part of the UBL specification. Another
document that may be useful in understanding the strategy may be the paper
I wrote with Arofan Gregory [1].

All that being said, I do agree with you that if the NDR specification is to
stand by itself (and not as part of the UBL specification, as it was intended
for most of its life) it should make reference to extensibility mechanisms.
Hopefully it will reference the UBL ones, as the goal of producing documents
that can be legally binding is shared.

Thanks!

Eduardo

[1] http://www.idealliance.org/papers/dx_xml03/papers/04-04-04/04-04-04.html



On 10/08/2004 11:47 AM, comment-form@oasis-open.org wrote:
> 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]