RE: [Requirements] Non-requirement for MEPs

Patil:

Having some sort of explicit error message is useful, however the
exception types must be limited to the ones that will be used in the
choreography definition to specify alternate paths, i.e. paths to
process the exceptions. I am not sure that you may need to specify a
different path whether the document is not well-formed, is not valid
because an element of the document is missing or an attribute content
does not conforms to its datatype. Of course you may want to convey back
the exact error message, but not as individual exception types.

So I concur with Assaf and don't think we need to detail a large number
of exceptions types.

JJ- 
 
 

>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]
>>On Behalf Of Patil, Sanjaykumar
>>Sent: Wednesday, March 19, 2003 1:20 PM
>>To: Assaf Arkin
>>Cc: public-ws-chor@w3.org
>>Subject: RE: [Requirements] Non-requirement for MEPs
>>
>>
>>
>>>> <Assaf>
>>>> I'm not sure there is much value in identifying specific faults, I
>>think
>>>> some coarse distinction will suffice.
>>
>>>> For example, the seller may send a message that the buyer cannot
>>validate.
>>>> The buyer can send back some fault. But the seller may validate the
>>message
>>>> on its side before sending it, determine the fault without having
to
>>receive
>>>> it from the buyer. The seller may find that it's implementation is
>>wrong and
>>>> it cannot proceed. It's able to fix the implementation but that may
>>take
>>>> longer than the transaction timeout. So suffice that the seller can
say
>>>> 'oops, something went wrong, let's decide to cancel the
transaction'. I
>>>> don't think there's need to delve into the what went wrong in much
>>detail,
>>>> coarse grain would work fine for all the scenarios I've seen.
>>>> </Asaaf>
>>
>>Even to say that "oops, something went wrong, let's decide to cancel
the
>>transaction", you need to know the exact type of the error. That is,
if
>>you wanted to define the behavior of the system to cancel the
transaction
>>for certain types of errors, you are already assuming that you can
>>identify the types of errors. Isn't specifying the type of the error
>>already getting into defining details of the error message!
>>
>>Once we support certain types of errors,  we may also have to augment
the
>>error message definitions with the exact information of the error
>>instance. For example, a content-validation-failed error message can
>>include the details of which element in which document was the
culprit.
>>
>>Yes, a coarse grained error type is useful in its own merit and we
could
>>include such a category to account for unidentified errors. However,
for
>>those functionalities that will be directly supported by the
choreography
>>specification, we need to clearly support the relevant error messages
>>also.
>>
>>
>>Sanjay Patil
>>Distinguished Engineer
>>sanjay.patil@iona.com
>>-------------------------------------------------------
>>IONA Technologies
>>2350 Mission College Blvd. Suite 650
>>Santa Clara, CA 95054
>>Tel: (408) 350 9619
>>Fax: (408) 350 9501
>>-------------------------------------------------------
>>Making Software Work Together TM

Received on Wednesday, 19 March 2003 13:57:17 UTC