RE: [ubl-cmsc] XSD Derivation

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

> -----Original Message-----
> From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
> Sent: Monday, November 26, 2001 7:33 AM
> To: 'Eduardo Gutentag'
> Cc: 'ubl-cmsc@lists.oasis-open.org'
> Subject: RE: [ubl-cmsc] XSD Derivation
> 
> 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.

On the one hand, it may be intuitively obvious to folks who are familiar
with polymorphism that it is a Good Thing to have processing code treat a
MyPrice (derived) as a Price (base).  I fear however, that as it stands, the
example is incomplete and as such will fail to provide maximal value to us
in evaluating our design alternatives (i.e. ebXML-style CDA vs. schema
extension).  (I realize Matt wasn't trying to provide a complete example --
I'm taking the opportunity, though, to use it as a jumping off point).

To put a finer point on it, I'd like to deconstruct the term "treat" as used
in Matt's example.  When processing code "treats" a MyPrice as a Price does
it treat elements present in MyPrice, but not in Price such that they are:

a) ignored for the purpose of processing
b) _exploited_
c) NOT stored (nor forwarded)
d) stored (and forwarded as appropriate)

Since the "document oriented" processing paradigm as it stands governs only
the transport of data (without attendant "processing code") it is actually
at odds with "polymorphism".  As it stands, the example suffers two possible
shortcomings.  These are familiar to the C++ community, the first is the
"slicing" problem:

  Slicing problem:  In C++ when an instance of a derived type is passed by
_value_ to a function that is 
  expecting an instance of a base type (as a parameter), the extra bits (the
parts of the derived type not present 
  in the base) are simply chopped off.

Slicing would occur in processing nodes where alternative (c) held.

The second issue is akin to the dynamic vs. static dispatch problem in C++.

  Dynamic dispatch: processing logic is selected, based on the _most_
_specific_ runtime type of an object.  This is in
  constrast to static dispatch where processing logic is selected based on
some compatible _base_ _type_ known at compile
  time.

Shall we prescribe any sort of dynamic dispatch paradigm.  If we do not then
(a) holds and we have no polymorphism.  Distributed polymorphism is of
course a Hard Problem.  In a toy system it's easy to have all the derived
types in the universe known at each processing node -- this becomes
untenable in our distributed case.  

I think it's easy enough to choose (d) over (c) and make that work, but (b)
is hard.  But just because it's hard, doesn't mean it's the wrong choice.
Further, I don't feel like the value of (a) has been proven.  So perhaps my
question boils down to: "is there any real value in alternative (a) in the
real world".  

I'll try to try to drive this to a crisper conclusion in the "Usage Cases"
thread.  Just wanted to take advantage of an opportunity to think (talk) in
terms of the processing code (rather than the XML structure).

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

Unless we can show some significant value added by abandoning standard
schema extensions, I agree that we should stick with them.  

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