[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AddRequest#psoID.
I want to change something in the spec. This change affects only one specific piece of text in the spec and does not in any way affect the XSD. I think the spec should say that when an addRequest supplies a psoID, the provider MUST use the specified psoID. If the provider cannot use the supplied psoID (e.g., because the psoID is invalid or because an object already exists with that psoID), then the provider MUST fail the request. The spec currently says that any psoID that is supplied in the addRequest is merely a *suggestion*, and that the provider will return the *actual* psoID in the response. (IIRC I'm the one who pushed that rule.) Looking at it now, the current behavior seems bad. It seems to me that if a requestor is supplying a psoID, that requestor really means that the object should have the specified psoID. (Presumably, the requestor already has a pretty good idea of a psoID that will be valid to the requestor.) Everywhere else that a request *specifies* an argument, the provider either honors the argument or fails the request. (The only exception I can think of is <capabilityData>, which we treat as kind of optional. In the case of <capabilityData>, the "mustUnderstand" flag controls whether the provider must-honor-or-fail.) I've presented this idea to Jeff Bohren and he agrees. (That's not surprising, since I think he originally wanted it to be this way.) If anyone objects, please reply to the list.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]