[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-cmsc] XSD Derivation
Aha, I missed this one. Well if the argument is that schema processor support is not there, I say: so what? We can reasonably assume that it will be by the time people start to use this stuff. Also, UBL could be a major driver to making this happen. Finally, what is the advantage to using an ad hoc derivation syntax (by definition supported by no one) rather than a standard derivation syntax (that can always be implemented ad hoc if standard support is not there)? I'm confused... > -----Original Message----- > From: Eve L. Maler [mailto:eve.maler@sun.com] > Sent: Monday, November 19, 2001 9:45 PM > To: ubl-cmsc@lists.oasis-open.org > Subject: Re: [ubl-cmsc] XSD Derivation > > > Some kinds of derivation allowed in the XSD spec > (restriction, substitution > groups) are not universally implemented. If we left these out of > consideration, and the question were just "Should XSD complex type > extension be used...?", I could see an argument for doing that in an > XSD-native way rather than performing a schema-to-schema > transformation. But there may be costs to treating this kind > of context > rule differently from the others. In short, I'm with Eduardo > on this one. :-) > > Eve > > At 04:18 PM 11/16/01 +0100, 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? > > -- > Eve Maler +1 781 442 3190 > Sun Microsystems XML Technology Center eve.maler @ sun.com > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC