[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]