Re: [provision] Spec issues #22 and #23: AddRequest targetID,con tainerID and psoID.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

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