[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [provision] Spec issues #22 and #23: AddRequest targetID,con tainerID and psoID.
Never mind; I see that Draft 19 removes this CHOICE from AddRequestType. I think issues 22 and 23 are resolved. I'll fix them in Spec Draft 8. Gary P Cole wrote: > But, Jeff, in XSD 18 AddRequestType required a choice of psoID | > containerID, right? > > <complexType name="AddRequestType"> > <complexContent> > <extension base="spml:RequestType"> > <sequence> > <choice> > <element name="psoID" > type="spml:PSOIdentifierType" /> > <element name="containerID" > type="spml:PSOIdentifierType" /> > </choice> > <element name="data" type="spml:ExtensibleType" /> > </sequence> > <attribute name="targetID" type="string" use="optional"/> > <attribute name="returnData" type="spml:ReturnDataType" > use="optional" default="everything"/> > </extension> > </complexContent> > </complexType> > > Bohren, Jeffrey wrote: > >> Gary, >> >> Neither a PSO ID nor a Container ID is required if the service >> determines >> the PSO ID (which should be the case in most scenarios). If the service >> determines the PSO ID, the PSO ID should never be passed on an >> AddRequest, >> regardless if the target supports containment or not. >> >> Jeff Bohren >> BMC >> >> -----Original Message----- >> From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] Sent: Tuesday, May 17, >> 2005 9:35 AM >> To: PSTC >> Subject: Re: [provision] Spec issues #22 and #23: AddRequest >> targetID, con >> tainerID and psoID. >> >> I'm sorry, Jeff. You're not confused; I was. I don't know where I >> got the idea that IdentifierType had targetID. Either my diffs were >> scrambled or I was. :-) >> >> What about the second point? Am I right that AddRequestType requires >> <psoID> when the target does not support containment? >> >> Bohren, Jeffrey wrote: >> >> >> >>> Gary, >>> >>> I'm confused here. In draft 18 the types are defined as: >>> >>> <complexType name="IdentifierType"> >>> <complexContent> >>> <extension base="spml:ExtensibleType"> <attribute name="ID" >>> type="string" use="optional"/> >>> </extension> >>> </complexContent> </complexType> >>> >>> <complexType name="PSOIdentifierType"> >>> <complexContent> >>> <extension base="spml:IdentifierType"> <sequence> >>> <element name="containerID" type="spml:IdentifierType" /> >>> </sequence> >>> <attribute name="targetID" type="string" use="optional"/> >>> </extension> >>> </complexContent> </complexType> >>> How does the Target ID attribute get defined twice? I don't see it. >>> >>> -----Original Message----- >>> From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] Sent: Monday, May 16, >>> 2005 11:55 AM >>> To: Jeff Bohren >>> Cc: PSTC >>> Subject: Re: [provision] Spec issues #22 and #23: AddRequest >>> targetID, con >>> tainerID and psoID. >>> >>> I'm looking at XSD 18, and I have a couple of minor >>> issues/comments/suggestions: >>> >>> 1) PSOIdentifierType gets targetID twice. PSOIdentifierType adds a >>> targetID attribute to IdentifierType, which already has a targetID >>> attribute. >>> Either IdentifierType should not define the targetID attribute (in >>> which case we don't really need IdentifierType), or >>> PSOIdentifierType should not add it. (If you ask me, I'd suggest >>> getting rid of IdentifierType. Why do we need this?) >>> >>> 2) The CHOICE in AddRequestType is still a problem. Now it's down >>> to a choice of <psoID> or <containerID>, but that means that a >>> requestor *must* specify <psoID> if the target does not support >>> containment. That seems wrong. >>> >>> I think we should get rid of the CHOICE in AddRequestType. Just >>> make <psoID> and <containerID> both optional, and we'll say that it >>> is an error to specify a <containerID> that conflicts with any >>> containerID in the <psoID>. >>> >>> Gary P Cole wrote: >>> >>> >>> >>> >>> >>>> Okay; I can go along with that approach to containerID. It is >>>> consistent and it is explicit. >>>> >>>> I still don't know whether I'm comfortable with the larger issue >>>> (that is, addRequest's choice of targetID, containerID and psoID), >>>> but I'll take a look at XSD 18. This certainly helps. >>>> >>>> Bohren, Jeffrey wrote: >>>> >>>> >>>> >>>> >>>>> The containerID must always be included in the PSO ID if there is a >>>>> container. There would not be a container for root PSOs or PSOs on >>>>> a target >>>>> for which containment is not supported. >>>>> >>>>> If you look at various tree APIs, you will see that the semantic for >>>>> creating a top level node is often to create a node without a >>>>> parent. This >>>>> is a very common idiom and should not cause too much confusion. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail. You may a link to this group and all your TCs >>>> in OASIS >>>> at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. You may a link to this group and all your TCs in >>> >> >> OASIS >> >> >>> at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs >> in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs >> in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]