OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

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