Re: [provision] CancelResultsType seems redundant.

[Darran Rolls <Darran.Rolls@sun.com>]

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_workgroup.php. 
>
>