Re: [ubl-comment] Public Comment

[Eduardo Gutentag <Eduardo.Gutentag@Sun.COM>]

There is an assumption that validation against the proper schema will
take place at the receiving end. Business scenarios include agreements
before the exchange of documents; agreements can include things as
trivial as the location of the schema(s) to be used in the exchange
of documents.

And yes, I agree that some text should perhaps be added to the document
to highlight these issues.

Thanks!

On 10/09/2004 08:45 AM, David Orchard wrote:
> Hi Eduardo,
> 
> Thanks for the response!  I have indeed read your paper and I refer to
> it from some of my writings.  I think I understand the central issue of
> wanting to ensure legally binding contracts.  
> 
> It is my thinking that if extensions do not over-ride any semantics,
> then the contract should still be legally binding.  And so I thought if
> there was ever a chance to get distributed extensibility in UBL, this
> would be the last time I could comment.  Hence why I proffered my
> comments.  
> 
> I guess I do have one question, which is that I don't see quite how it
> is possible to do distributed compatible evolution.  How does one side
> evolve without breaking the other, given that the ns names are changed
> and the new types are not sent with instances?
> 
> I retain my concern that people who do not understand the strict scoping
> of UBL will start referring to the UBL naming rules.  Perhaps some more
> material explaining the narrow and legally focused scoping context for
> UBL Naming would help?  Or even some text around "if UBL had wanted a
> more general purpose solution, then other alternatives using wildcards
> would have been examined?"  
> 
> Cheers,
> Dave
> 
> 
>>-----Original Message-----
>>From: Eduardo Gutentag [mailto:Eduardo.Gutentag@Sun.COM]
>>Sent: Saturday, October 09, 2004 3:49 AM
>>To: David Orchard
>>Cc: ubl-comment@lists.oasis-open.org; Norman Walsh; Arofan Gregory
>>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/ExtendingAndVersion
> in
> 
>>gXMLLanguages.html
>>
>>>
>