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.


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]