[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.
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]