RE: [provision] CancelResultsType seems redundant.

["Cohen, Doron" <Doron_Cohen@bmc.com>]

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.