Re: Modication to Nick's Fault Handling Proposal

Gary Brown wrote:

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

mm1: One additional comment on Nick's proposal, can you explain why the 
choice of respond messages is implicit rather than explict. Thanks.

> Regards
> Gary
>
>     ----- Original Message -----
>     *From:* Nickolas Kavantzas <mailto:nickolas.kavantzas@oracle.com>
>     *To:* Gary Brown <mailto:gary@enigmatec.net>
>     *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 <mailto:gary@enigmatec.net>
>         *To:* public-ws-chor@w3.org <mailto: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
>

Received on Tuesday, 2 November 2004 17:23:13 UTC