Re: [provision] element ref won't work.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

I'm no expert on XML Schema, but I see three approaches that may work.

Option 1: CHOICE - Specify a choice of derived types.
PRO:  Explicit (and therefore validated by parser).
CON: Not extensible (won't accept custom request types).
 
For example,  BatchRequestType would contain
     <sequence>
          <choice minOccurs="1" maxOccurs="unbounded">
             <xsd:element ref="addRequest"/>
             <xsd:element ref="modifyRequest"/>
             <xsd:element ref="deleteRequest"/>
          </choice>
    </sequence>

Option 2: WRAPPER - Instance of derived type is open content of wrapper 
element.
PRO:  Open (will accept custom request types).
CON: Implicit (parser cannot validate open content).
 
For example,  BatchRequestType would contain
     <sequence>
          <element name='bRTWrapper" type="BRTWrapperType" minOccurs="1" 
maxOccurs="unbounded">
    </sequence>

Option 3: XSI TYPE - XSD defines element as base type, instance 
specifies derived type.
PRO:  Open (will accept custom request types).
CON: Fancy feature (some tools may not support "xsi:type").
CON: Burdens requestor (who must specify derived type).
 
For example,  BatchRequestType would contain
     <sequence>
          <element name="nestedRequest" type="BatchableRequestType" 
minOccurs="1" maxOccurs="unbounded">
    </sequence>

Each nested request in a batchRequest must specify its derived type.  
For example,
<batchRequest>
    <nestedRequest xsi:type="spml:AddRequestType" ....>
    <nestedRequest xsi:type="spml:AddRequestType" ....>
</batchRequest>

gpc

Gary P Cole wrote:

> Enhanced subject in order to get attention.
>
> Gary P Cole wrote:
>
>> 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
>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster 
>> of the OASIS TC), go to 
>> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. 
>>
>>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php. 
>
>