Re: Modication to Nick's Fault Handling Proposal

So, just to clarify, an exchange could reference an ExceptionInformationType, and have 'causeException=false', and would therefore not jump to an exception workunit.

If this statement is correct, then it appears to be an inconsistent use of the ExceptionInformationType. In cases where information is assigned to an exception type variable, I believe your proposal states that this would cause an exception:

"· A Variable defined with informationType having the attribute exceptionType
set to "true" is an Exception Variable and causes an Exception to occur at a party when
populated"

I think we need to ensure the concepts in the fault handling proposal are consistent in different parts of the specification, otherwise CDL authors will get confused. In this respect, it may be simplier for users if setting an instance of an ExceptionInformationType always raises an exception.

Regards
Gary
  ----- Original Message ----- 
  From: Nickolas Kavantzas 
  To: Gary Brown 
  Sent: Friday, October 29, 2004 11:11 PM
  Subject: Re: Modication to Nick's Fault Handling Proposal


  Gary, i am not sure that you have to do anything in order to accomodate what you intend.

  Exception workunits are triggered only when an ExceptionInformationType variable is populated  AND  
  "causeException=true'" is specified. But "causeException=true'" is not always required to be 
  specified (even if you are populating an ExceptionInformationType variable).


  This is already supported by my proposal. If it is not clear then we need to put more/better english.

  --
  Nick

  ----- Original Message ----- 
    From: Gary Brown 
    To: public-ws-chor@w3.org 
    Sent: Friday, October 29, 2004 4:25 AM
    Subject: Modication to Nick's Fault Handling Proposal


    This email outlines a modification to Nick's original fault handling proposal, to enable fault messages to be received without triggering an exception.

    The original proposal is at: http://lists.w3.org/Archives/Public/public-ws-chor/2004Oct/0026.html

    Following the description of the new interaction syntax, there are a set of rules associated with the exchange part. The third rule states:

    "When multiple respond message exchanges are specified, one respond
    message MUST be of normal informationType and all the others MUST be of exception
    informationType. There is an implicit choice between the respond exchanges"

    This rule declares that all but one of the exchanges must refer to an exception information type - which when populated, would automatically cause an exception to be thrown (according to the rules associated with an exception information type).

    Therefore, to minimise the changes to this proposal, I would suggest that we drop this rule, to enable more than one of the respond exchanges to be associated with information types. This means that in the case of a fault, the fault type would be declared as an information type without the 'exceptionType="true"'' - and therefore it would be treated as a normal information type.

    It may be a requirement to add a new rule which states that "the first 'respond' exchange MUST relate to the normal message response, with any subsequent 'respond' exchange being associated with a fault". Alternatively, the action field could be changed to 'fault' for any non-normal response.

    Regards
    Gary