Re: [ubl-cmsc] XSD Derivation

[Eduardo Gutentag <eduardo.gutentag@sun.com>]

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).

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?

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.



Matthew Gertner wrote:
> 
> This seems to be the only point where I have a strong opinion that is not
> the same as yours and Eve's. How boring...
> 
> In this case, I feel strongly that XSD derivation should ALWAYS be used when
> creating extensions. Sorry to go "visionary" on you guys, but I'm convinced
> that the whole power of schema is that standard processing tools can be
> used. One of the really clever things that these standard processing tools
> will do is to be able to treat extended types that they don't know as if
> they were base types that they do know. In other words, I might use a schema
> processor to write code to process a Price type. If someone sends a MyPrice
> (derived from Price) to my processor, it will just see a Price since the
> schema processor will deal with hiding the extensions, restrictions, etc.
> 
> I'm not flying entirely blind here, since this is the way that existing
> schema processors, like Commerce One's XDK, work.
> 
> We want to design a framework that exploits the power of these future schema
> processors, and this means that UBL extensions should be standard schema
> extensions supported by standard schema processors. Also, I haven't heard
> anyone suggest that we should allow extensions that aren't permitted in XSD,
> although it was implied by Eduardo and Eve's mails that this might be
> desirable. Can someone provide an example?
> 
> Matt
> 
> > -----Original Message-----
> > From: Eduardo Gutentag [mailto:eduardo.gutentag@sun.com]
> > Sent: Friday, November 16, 2001 11:50 PM
> > To: Matthew Gertner
> > Cc: 'ubl-cmsc@lists.oasis-open.org'
> > Subject: Re: [ubl-cmsc] XSD Derivation
> >
> >
> > Matthew Gertner wrote:
> > >
> > > 2) Should XSD derivation be used when context rules are
> > applied: always,
> > > sometimes or never? In others, what is the derivation
> > relationship, if any,
> > > between contextual components and the base components that
> > yielded them?
> >
> > Another way of posing the question would be:
> > Should context rules be applied as
> > a) a schema to schema tranform to avoid the restrictions
> > imposed by XSD derivation?
> > or as
> > b) XSD derivation to preserve the derivation relationship?
> >
> > I have to confess that at this point I'm extremely agnostic
> > on this point, since
> > I can see the advantages of both...but I'm ready to be
> > lobbied for one way or another.
> >
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > --
> > Eduardo Gutentag               |         e-mail:
> > eduardo.gutentag@Sun.COM
> > XML Technology Center          |         Phone:  (510) 986-3651 x73651
> > Sun Microsystems Inc.          |
> >

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
XML Technology Center          |         Phone:  (510) 986-3651 x73651
Sun Microsystems Inc.          |