Re: [provision] CancelResultsType seems redundant.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

That sounds great. 

I had been thinking (because CancelResultsType enumerates a value of 
'couldNotCancel' even though any error seems to trump cancelResult) that 
perhaps we needed to recognize a situation in which there is no error 
but a provider simply cannot cancel an async operation. 

Your approach is much clearer: If a provider is unable to cancel an 
async operation, the cancelResponse should  specify "result='failure'" 
and an appropriate value of "error".
 
Cohen, Doron wrote:

>Gary,
>
>The question is "what is it that caused the failure to cancel?" 
>
>If it is because there is not such request than this would also be
>applicable for statusRequest and the PSP should use noSuchRequest. 
>
>If there is a different reason, the error code should state what it is - in
>general, the error should add information for the requestor so it better
>understand the cause of the failure (that was indicated in the result). 
>In that regard I would like to see error codes that do that and are not
>generic like A or even B below.
>
>Doron
>
>-----Original Message-----
>From: Gary P Cole [mailto:Gary.P.Cole@Sun.COM] 
>Sent: Monday, November 22, 2004 6:28 PM
>To: PSTC
>Subject: Re: [provision] CancelResultsType seems redundant.
>
>
>Has anyone been able to imagine a case that requires CancelResultsType? 
>(It is possible that a corner case existed in the SPML 1.0 binding that 
>would no longer occur.)
>
>CancelResultsType is redundant with "result" and "error".  Unless we can 
>think of a case that requires CancelResultsType, the only question that 
>remains is:
>1) What "error" should a provider return when it cannot cancel an async 
>operation?
>     A) 'unableToComply' (which is very general)
>     B) 'couldNotCancel' (which is very specific)
>     C) 'customError' (which could be misleading)
>     D) None.  (After all, the "error" attribute is optional.)
>
>I'd like to know what everyone else thinks, but I'll volunteer to go 
>first. 
>Option A is my first choice. The more general error code may be useful 
>for other operations. Option B is my second choice.   This error code 
>value would be specific to this operation.
>(Option C is legal but was probably intended to let providers return 
>their own errors, so it is a poor fit to this case.)
>(Option D is legal but bad form.  Everywhere else that 
>"result='failure'", I say that the response must specify an ErrorCode.)
>
>gpc
>Darran Rolls wrote:
>
>  
>
>>I  *think* this was a specific corner case that prompted this.  Does 
>>anyone recall without a costly trawl through the archive?
>>
>>Darran
>>
>>Gary P Cole wrote:
>>
>>    
>>
>>>I may be missing something, but I don't think we need 
>>>CancelResultsType (nor the cancelResult attribute in 
>>>CancelResponseType).
>>>NOTE: If you bore easily, feel free to skip the following analysis.
>>><analysis>
>>>ErrorCode already enumerates a value of 'noSuchRequest'.  (It must 
>>>because the status operation doesn't have a StatusResultsType.  If 
>>>you ask for status on a non-existent operation, the StatusResponse 
>>>must specify error='noSuchRequest'.)
>>>
>>>The way I see it, one of four things can happen to a cancel operation:
>>>1) success
>>>2) a failure because the operation we're supposed to cancel doesn't 
>>>exist
>>>3) a failure because the operation we're supposed to cancel wouldn't die
>>>4) a failure unrelated to the operation we're supposed to cancel
>>>
>>>As I read the XSD right now, here's what the CancelResponse would 
>>>return:
>>>1) result='success'; [no error]; cancelResult='canceled'
>>>2) result='failure';    error='noSuchRequest'; 
>>>cancelResult='noSuchRequest'
>>>3) result='success'; [no error]; cancelResult='couldNotCancel'
>>>4) result='failure';    error='<something>'; [no cancelResult]
>>>
>>>I figure that we're supposed to say result='success' in case #3 
>>>because no value of ErrorCode would seem to apply (except possibly 
>>>customError).  However, this reminds me of a doctor saying that "the 
>>>operation was a success, but the patient died."
>>>
>>>I also get the feeling that an error is supposed to pre-empt the 
>>>cancelResult.  If not, I guess we'd have to say 
>>>cancelResult='couldNotCancel' in case #4, even though a failure 
>>>unrelated to the operation we're supposed to cancel (e.g., 
>>>malformedRequest) prevented us from trying.
>>>
>>>The bottom line is that I don't think we really need "cancelResult".
>>>1) if the cancel succeeds, you already have "result='success'
>>>   so you don't need "cancelResult='canceled'".
>>>2) if the cancel fails with requestID not found,
>>>   you have "result='failure'" and "error='noSuchRequest'"
>>>   so you don't need "cancelResult='noSuchRequest'".
>>>3) if the cancel fails because you could not cancel the asynchronous 
>>>operation,
>>>   you have "result='failure'" (although it's not clear what the 
>>>error should be)
>>>   so you don't need "cancelResult='couldNotCancel'".
>>>4) if the cancel fails for some reason unrelated to the asynchronous 
>>>operation,
>>>   you have "result='failure'" and "error='whatever'"
>>>   so you don't need "cancelResult".  In fact, "cancelResult" could 
>>>be misleading.
>>></analysis>
>>>
>>>I think it should be this way:
>>>1) result='success' (means that the target operation was canceled)
>>>2) result='failure' and error='noSuchRequest' (means the target 
>>>operation was not found)
>>>3) result='failure' and error='customError' (means the target 
>>>operation was not canceled)
>>>4) result='failure' and error='whatever' (means an unrelated failure 
>>>prevented cancellation)
>>>
>>>If we don't like using 'customError' in case #3, we can add another 
>>>value of ErrorCode.  I would prefer something general (like 
>>>'unknownError' or 'couldNotPerform') rather than something as 
>>>specific as 'couldNotCancel'.
>>>
>>>gpc
>>>
>>>
>>>To unsubscribe from this mailing list (and be removed from the roster 
>>>of the OASIS TC), go to 
>>>
>>>      
>>>
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro
>up.php. 
>  
>
>>>      
>>>
>>To unsubscribe from this mailing list (and be removed from the roster 
>>of the OASIS TC), go to 
>>
>>    
>>
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro
>up.php. 
>  
>
>>    
>>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the
>OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro
>up.php.
>  
>