[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] element ref won't work.
Of all these, I like Option 3 (XSI-TYPE) the best. It's the closest to the way you originally wrote the XSD. Explaining how a requestor 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 be broadly supported. Since this is how the XML Schema Primer says to embed derived types as instances of the base type, I'm hopeful (but not 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 > >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. > > >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_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]