Re: [ubl-cmsc] XSD Derivation

["Eve L. Maler" <eve.maler@sun.com>]

This thread has given me many new things to think about.  A few comments below.

At 04:46 PM 11/26/01 -0800, Eduardo Gutentag wrote:
>I know that in my original message I said I was entirely agnostic and was 
>ready
>to be lobbied one way or another.
>
>However, I can't avoid playing devil's advocate; there are some things 
>that must
>be clarified before a decision is made.
>
>a) Tools will do this, tools will do that.
>With Eve (and others, of course) I participated in the development of 
>DocBook; one
>of the guiding principles of that effort was that whatever was added to 
>DocBook
>had to be supported consistenly by existing tools. This was when one
>"faction" in the SGML community was hoarsely declaring that it should have all
>kinds of things because the tools were just around the corner. Our 
>response was
>a polite "bollocks". Time proved that the tools never materialized. And 
>DocBook
>went to become a success story, which it wouldn't have if it had had all
>those things that utterly depended on non-existent tools. (NB: this 
>argument does
>not apply to the context rules language as in v1.04; those are just an 
>expression of
>what to do - they could (conceivably) be written in plain text; they could 
>also
>be implemented by hand; they are not tool-bound).

Admittedly, the SGML market then was tiny and had no influence, compared to 
the tools vendors jockeying for position today.  Even so, I think Eduardo 
has a point: We need to be careful about relying on promised support, and 
instead demand real support in at least two of the top validators.  That's 
why the NDR group made a list of validators that we want to test 
against.  Otherwise what we do will be merely theoretical.

>b) myIgnorance
>I'd really like to know how Commerce One's XDK works. Bill Burcham's email 
>in this
>regard rises all kinds of questions. What happens, for instance, when my 
>processor
>just sees "a Price since the schema processor will deal with hiding the 
>extensions,
>restrictions, etc." -- first of all, why is this so desirable? Isn't the 
>assumption
>behind all of this that if someone sends me a price that contains, say, 
>tax information
>that is applicable in NAFTA commerce, I should see it? Why would it be an 
>advantage
>to have my application not process it? (and please, this is just a silly 
>example,
>whether Price ever contains tax info is irrelevant). What I want
>to know is in what measure one can treat legally binding documents as if 
>they were
>software objects that may be treated more or less accurately. One other 
>way of expressing
>this, and I apologize for perhaps asking the same question in various 
>ways, is: if
>I'm so concerned with my application getting the right information that I 
>go to the
>trouble of validating the documents being interchanged, why would I be so 
>cavalier
>as to want to hide some of the information contained in those documents? 
>Wouldn't I
>want to know that my application is not ready to deal with a particular 
>kind of
>document?

I echo Bill's and Eduardo's questions here.  In the SAML context, people 
have talked about the need to process extensions with "maximum 
understandability"; for example, if you extend SAML to add your own kinds 
of assertions, SAML-conforming systems should be able to detect that 
they're a particular flavor of SAML assertion.  However, SAML is not going 
the route of negotiating or generating business-context-specific schemas, 
the way UBL is.  Does the addition of context negate the need to squeeze 
this sort of information out of the type hierarchy?

>c) XSD extensions
>I'm not sure about Eve's mail (I'll let her speak for herself), but what I 
>was
>hinting at were things like being able to add only to the end of a sequence of
>elements, not at the beginning or the middle, or changing the order, for 
>instance.
>Whether that's desirable or not it's another question, I was just referring to
>some constraints.

It seems that the big case of non-XSD-friendly extension, and perhaps the 
only really juicy example, is addition of elements to places in content 
models other than the end.  Particularly for machine-to-machine 
applications such as UBL, subelement order shouldn't carry significant 
semantics, such that adding things only to the end should be 
safe.  However, are we missing any use cases for adding things to the 
beginning or middle?

         Eve
--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com