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: Spec issues #22 and #23: AddRequest targetID, containerID and psoID.


Agreed during the 20050510 conference call to discuss these issues on 
the list.
Forwarding "AddRequest targetID, containerID and psoID" originally 
posted to the list 4/21/05.
--- Begin Message ---
Bohren, Jeffrey wrote:

>Line 962: An add request may omit both the target ID and container ID if the
>PSP has only one target and containment is not being specified. 
>
This seems reasonable, but is this what the XSD says?

In XSD 15,  spml:AddRequestType requires a choice of targetID or 
containerID.  As I understand it, an xsd:choice requires exactly one of 
the elements it contains.

XSD 16 adds a <psoId> element to the same choice.  However, I think this 
may be wrong, since the option to specify a <psoId> should not exclude 
specifying <targetId> or <containerId>. I think the <psoId> element 
should be outside the CHOICE and should be MINOCCURS=0.

Personally, I don't think it's such a bad thing to require targetID 
(even if the provider exposes only one target).  This helps keep the 
choice (between target and container) clear. 

Another approach would be to make targetID and containerID both 
optional. (For the purposes of this discussion, I don't think it matters 
much whether they are elements or attributes.) The only problem I can 
see would arise only if all of the following were true:
1) containerID is an element that contains a targetID.
2) requestor specifies both targetID and containerID.
3) targetID in the containerID conflicts with the specified targetID.
I think we could handle this problem just by stating normatively in the 
spec that such a conflict is an error.

>Also an add
>request MAY contain a PSO ID. This section implies otherwise.
>  
>
It seems reasonable that a requestor may suggest a psoID. However, I 
don't think that the XSD said this.  We may want to change the XSD.

In XSD 15, AddRequestType requires either targetID or containerID, and 
allows the requestor to specify <data>.  As we've specified the format 
of LookupResponseType and the behavior of the ReturnDataType, <data> 
does not include <psoId>.

XSD 16 adds <psoId> to the choice of targetID or containerID, but I 
think this is wrong.  The option to specify a <psoId> should not exclude 
specifying <targetId> or <containerId>. I think the <psoId> element 
should be outside the CHOICE and should be MINOCCURS=0.

--- End Message ---


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