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: [no subject]


<batchRequest>
  <addRequest>...</addRequest>
  <modifyRequest>...</modifyRequest>
</batchRequest>

is the same as:

<batchRequest>
  <nestedRequest xsi:type=3D"AddRequestType">...</nestedRequest>
  <nestedRequest xsi:type=3D"ModifyRequestType">...</nestedRequest>
</batchRequest>

but less complicated.

Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc
=20
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.
=20
=20

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

Of all these, I like Option 3 (XSI-TYPE) the best.  It's the closest to=20
the way you originally wrote the XSD.  Explaining how a requestor=20
specifies "xsi:type" in each nested request is pretty easy.

I think the only real drawback would be if "xsi:type" is too exotic to=20
be broadly supported.  Since this is how the XML Schema Primer says to=20
embed derived types as instances of the base type, I'm hopeful (but not=20
yet convinced) that this is a common technique.

Does anyone believe that "xsi:type" is too exotic to be broadly
supported?

Jeff Bohren wrote:

>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
>=20
>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.
>=20
>=20
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM]=20
>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=20
>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=20
>content of SpmlRequestType?)=20
>
>Option 4 does not indicate that there is a nested request, much less=20
>that there must be one or more of them.  I consider option 4 to be a=20
>degenerate (and inferior) form of Option 2.  At least we can give a=20
>WRAPPER element a good name. We can also specify  minOccurs and=20
>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. =20
>Why would we change the BatchRequestType to be almost completely=20
>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.=20
>
>Have I overlooked something compelling about Option 4 (or something=20
>really bad about Options 1, 2 and 3)?
>
>Jeff Bohren wrote:
>
> =20
>
>>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=3D"BatchRequestType">
>>		<complexContent>
>>			<extension base=3D"spml:RequestType">
>>				<sequence>
>>				</sequence>
>>				<attribute name=3D"processing"
>>type=3D"spmlbatch:ProcessingType" use=3D"optional" =
default=3D"sequential"/>
>>				<attribute name=3D"onError"
>>type=3D"spmlbatch:OnErrorType" use=3D"optional" default=3D"exit"/>
>>			</extension>
>>		</complexContent>
>>	</complexType>
>>
>>	<complexType name=3D"BatchResponseType">
>>		<complexContent>
>>			<extension base=3D"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]=20
>>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=3D"1" maxOccurs=3D"unbounded">
>>            <xsd:element ref=3D"addRequest"/>
>>            <xsd:element ref=3D"modifyRequest"/>
>>            <xsd:element ref=3D"deleteRequest"/>
>>         </choice>
>>   </sequence>
>>
>>Option 2: WRAPPER - Instance of derived type is open content of
wrapper
>>   =20
>>
>
> =20
>
>>element.
>>PRO:  Open (will accept custom request types).
>>CON: Implicit (parser cannot validate open content).
>>
>>For example,  BatchRequestType would contain
>>    <sequence>
>>         <element name=3D'bRTWrapper" type=3D"BRTWrapperType"
>>   =20
>>
>minOccurs=3D"1"
> =20
>
>>maxOccurs=3D"unbounded">
>>   </sequence>
>>
>>Option 3: XSI TYPE - XSD defines element as base type, instance=20
>>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=3D"nestedRequest" type=3D"BatchableRequestType" =

>>minOccurs=3D"1" maxOccurs=3D"unbounded">
>>   </sequence>
>>
>>Each nested request in a batchRequest must specify its derived type. =20
>>For example,
>><batchRequest>
>>   <nestedRequest xsi:type=3D"spml:AddRequestType" ....>
>>   <nestedRequest xsi:type=3D"spml:AddRequestType" ....>
>></batchRequest>
>>
>>gpc
>>
>>Gary P Cole wrote:
>>
>>=20
>>
>>   =20
>>
>>>Enhanced subject in order to get attention.
>>>
>>>Gary P Cole wrote:
>>>
>>>  =20
>>>
>>>     =20
>>>
>>>>I could very easily be wrong about this (and I hope that I am), but=20
>>>>I'm not sure that simply *referring* to elements will do what we
>>>>    =20
>>>>
>>>>       =20
>>>>
>>want.
>>=20
>>
>>   =20
>>
>>>>For example, BatchRequestType now *refers* to the a global element=20
>>>>"spml:request".
>>>>  <element ref=3D"spml:request" minOccurs=3D"1" =
maxOccurs=3D"unbounded"/>
>>>>We *want* this to allow any element that extends SpmlRequestType to=20
>>>>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=20
>>>>ref=3D"comment" minOccurs=3D"0">
>>>>This allows the same element to occur in multiple places, but the=20
>>>>name of the element is always "comment".
>>>>
>>>>There is also an example of using a derived type (see "4.3 Using=20
>>>>Derived Types in Instance Documents"), but even in this example the=20
>>>>*name* of the element that is of a derived type matches the name of=20
>>>>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=20
>>>>batchableRequestType--but I'm not sure that this will do it.
>>>>Perhaps we can add a level of indirection--a wrapper element--to=20
>>>>contain each instance of a nested request.  Or perhaps we must=20
>>>>specify this as a choice of (a fixed set of) types derived from=20
>>>>batchableRequestType.
>>>>
>>>>Can someone please clarify (and dispossess me of this notion)?
>>>>
>>>>gpc
>>>>
>>>>
>>>>To unsubscribe from this mailing list (and be removed from the
roster
>>>>    =20
>>>>
>>>>       =20
>>>>
>>=20
>>
>>   =20
>>
>>>>of the OASIS TC), go to=20
>>>>
>>>>    =20
>>>>
>>>>       =20
>>>>
>>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_w
o
>>   =20
>>
>r
> =20
>
>>kgroup.php.=20
>>=20
>>
>>   =20
>>
>>>>    =20
>>>>
>>>>       =20
>>>>
>>>To unsubscribe from this mailing list (and be removed from the roster

>>>of the OASIS TC), go to=20
>>>
>>>  =20
>>>
>>>     =20
>>>
>>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_w
o
>>   =20
>>
>r
> =20
>
>>kgroup.php.=20
>>=20
>>
>>   =20
>>
>>>  =20
>>>
>>>     =20
>>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster
>>   =20
>>
>of
> =20
>
>>the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_w
o
>>   =20
>>
>r
> =20
>
>>kgroup.php.
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster
>>   =20
>>
>of the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wo
r
>kgroup.php.
> =20
>
>>=20
>>
>>   =20
>>
>
>
>
>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.
>
> =20
>



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]