[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] element ref won't work.
Option 2 is functionally the same as option 4 but with an extra (and
unnecessary) wrapper element. Both options use the open content model to
allow different request types to be included in a batch. I fail to see
how:
<batchRequest>
<bRTWrapper>
<addRequest> .... </addRequest>
</bRTWrapper>
<bRTWrapper>
<modifyRequest> .... </modifyRequest>
</bRTWrapper>
</batchRequest>
is better than:
<batchRequest>
<addRequest> .... </addRequest>
<modifyRequest> .... </modifyRequest>
</batchRequest>
It adds complexity for no added benefit.
Let me also suggest an option 5:
Use a choice for the core request (add, mod, etc), but all other request
would be allowed via the open content model.
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 10:13 AM
To: PSTC
Subject: Re: [provision] element ref won't work.
Nesting requests as open content of the BatchRequestType--call this
approach Option 4--may be the *easiest* solution, but I don't think much
of it. (If we wanted to do this, why not leave *everything* as open
content of SpmlRequestType?)
Option 4 does not indicate that there is a nested request, much less
that there must be one or more of them. I consider option 4 to be a
degenerate (and inferior) form of Option 2. At least we can give a
WRAPPER element a good name. We can also specify minOccurs and
maxOccurs for a wrapper element. Option 4 lacks both of these
advantages.
We've just gone through and added a <data> sub-element to the <pso> type
in order to make its content model (while still open) more explicit.
Why would we change the BatchRequestType to be almost completely
implicit (when there are three options that are reasonably explicit)?
I think that any of Options 1, 2 or 3 would be better than 4.
Have I overlooked something compelling about Option 4 (or something
really bad about Options 1, 2 and 3)?
Jeff Bohren wrote:
>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_wo
r
>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_wo
r
>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_wo
r
>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]