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