CancelResultsType seems redundant.

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

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