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