[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] element ref won't work.
Nowhere have we left a specified aspect of the protocol to be represented purely as open content. In fact, we've taken pains to add at least a wrapper for each specified aspect of the protocol. I'd point to <schema>, <capabilityData> and <data> as examples. Jeff Bohren wrote: >The hard reality is that given the extensive usage of the open content >model in our XSD, parsers will not be able validate anything other than >the presence of required elements (if they even do that). If we wanted >stronger parser validation to be supported, we would have to remove the >open content model everywhere we wanted that type of validation to >occur. > >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 3:46 PM >To: PSTC >Subject: Re: [provision] element ref won't work. > >I'm not sure that I disagree (with the open content approach). However, >I wonder why you object so strenuously to a "nestedRequest" wrapper >element when you didn't object to adding the <data> sub-element to >PSOType? Perhaps the analogy is imperfect, but I see more value in >wrapping something that occurs 1+ times than in wrapping something that >occurs 1? (or exactly once). > >I *do* disagree with your statement that there is no difference between > <sequence> > </sequence> >and > <sequence> > <element name="nestedRequest" type="BatchableRequestType" >minOccurs="1" maxOccurs="unbounded" /> > </sequence> >The second approach allows a parser to validate that (within an instance > >of BatchRequestType): >1) elements of or derived from BatchableRequestType >2) occur in a specified sequence >3) with a specified cardinality >With the "wrapper" approach the parser cannot validate 1, but it can >still validate 2 and 3. It seems to me that either the "xsi:type" or >the "wrapper" approach simplifies validation and parsing. > >You say we decided that a <batchRequest> should look like: ><batchRequest> > <addRequest>...</addRequest> > <modifyRequest>...</modifyRequest> ></batchRequest> >and that we should not allow XSD to complicate this. This wouldn't be >the first time that we've had to adjust the form of a request to make it > >work in XSD. Remember all the fuss about PSOIdentifierType? Remember >the fuss about TargetType and SchemaType? > >I know it is frustrating to discover this late in the game that we have >a problem. I also see how difficult it is to express something >"polymorphic" in XSD. But we need to be constructive and open-minded in > >developing and evaluating the various options. > >gpc > >Jeff Bohren wrote: > > > >>We should not be letting the tail wag the dog. The most important thing >>is the SPML protocol itself, not the XSD. The XSD is merely a means to >>document the protocol. The XSD is NOT the protocol. >> >>We have decided as a committee that a batch request looks like: >> >><batchRequest> >> <addRequest>...</addRequest> >> <modifyRequest>...</modifyRequest> >></batchRequest> >> >>This is simple, easy to describe, and easy to understand. This is how >>SPML 1.0 worked and this is how SPML 2.0 should work as well, XSD >> >> >issues > > >>aside. >> >>Under no circumstances will I agree to make the SPML protocol more >>complicated just to satisfy "XSD Purity". That may seem like an extreme >>position, but SPML has gotten complicated enough already. If we can't >>make something work at all, that is one thing. But this is not the >> >> >case. > > >>Using the open content model with normative text is acceptable and >>consistent with other parts of the SPML 2.0 spec. >> >>Also, using xsi:type adds zero value to the solution. It still defers >>definition of the requests to runtime, just like the open content model >>does. This just is a more complicated way to express the exact same >>information, with possible support issues thrown in just for fun. >> >> >> >>From a logical standpoint: > > >><batchRequest> >> <addRequest>...</addRequest> >> <modifyRequest>...</modifyRequest> >></batchRequest> >> >>is the same as: >> >><batchRequest> >> <nestedRequest xsi:type="AddRequestType">...</nestedRequest> >> <nestedRequest xsi:type="ModifyRequestType">...</nestedRequest> >></batchRequest> >> >>but less complicated. >> >>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: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 >> >> > > > >>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_ >>>> >>>> >w > > >>>> >>>> >>>> >>>> >>o >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>>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_ >>>> >>>> >w > > >>>> >>>> >>>> >>>> >>o >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>>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_ >>>> >>>> >w > > >>>> >>>> >>>> >>>> >>o >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>>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_w >>> >>> >o > > >>> >>> >>> >>> >>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_w >>> >>> >o > > >>> >>> >>> >>> >>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]