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: RE: [provision] element ref won't work.



Actually the easiest solution to this is to not define anything in the
XSD and normatively define what the contents of the batch request are.
This similar to how we handle different provisioning data models.

In other words, define batch request as:

	<complexType name="BatchRequestType">
		<complexContent>
			<extension base="spml:RequestType">
				<sequence>
				</sequence>
				<attribute name="processing"
type="spmlbatch:ProcessingType" use="optional" default="sequential"/>
				<attribute name="onError"
type="spmlbatch:OnErrorType" use="optional" default="exit"/>
			</extension>
		</complexContent>
	</complexType>

	<complexType name="BatchResponseType">
		<complexContent>
			<extension base="spml:ResponseType">
				<sequence>
				</sequence>
			</extension>
		</complexContent>
	</complexType>

The only downside is that you don't have XSD based enforcement anymore.
Since we are doing this is other parts of SPML, I don't think it should
be a problem.

As a note of interest, this is also the approach that WS-Federation
takes with the different security token types that it supports.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
 
Try the industry's only 100% .NET-enabled identity management software.
Download your free copy of Universal IdP Standard Edition today. Go to
www.opennetwork.com/eval.
 
 

-----Original Message-----
From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
Sent: Thursday, December 02, 2004 1:28 AM
To: PSTC
Subject: Re: [provision] element ref won't work.

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_wor
kgroup.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_wor
kgroup.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_wor
kgroup.php.



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