[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] element ref won't work.
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]