[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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_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]