[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 ---
- From: Gary P Cole <Gary.P.Cole@sun.com>
- To: provision@lists.oasis-open.org
- Date: Thu, 21 Apr 2005 14:50:29 -0500
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]