OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: element ref.


I could very easily be wrong about this (and I hope that I am), but I'm 
not sure that simply *referring* to elements will do what we want.

For example, BatchRequestType now *refers* to the a global element 
"spml:request".
    <element ref="spml:request" minOccurs="1" maxOccurs="unbounded"/>
We *want* this to allow any element that extends SpmlRequestType to 
occur in this position.  I think, however, that this will only allow a 
<request> (or an <spml:request>) element to occur in this position.

The XML Schema Primer uses the example of "comment". 
    <element ref="comment" minOccurs="0">
This allows the same element to occur in multiple places, but the name 
of the element is always "comment".

There is also an example of using a derived type (see "4.3 Using Derived 
Types in Instance Documents"), but even in this example the *name* of 
the element that is of a derived type matches the name of the element as 
defined.

I know that we want this element to behave polymorphically--that is, to 
accept an element of any type that is derived from 
batchableRequestType--but I'm not sure that this will do it.
Perhaps we can add a level of indirection--a wrapper element--to contain 
each instance of a nested request.  Or perhaps we must specify this as a 
choice of (a fixed set of) types derived from batchableRequestType.

Can someone please clarify (and dispossess me of this notion)?

gpc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]