W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

RE: [Requirements] Non-requirement for MEPs

From: Patil, Sanjaykumar <sanjay.patil@iona.com>
Date: Wed, 19 Mar 2003 10:19:52 -0800
Message-ID: <EA3ECEFACBE7674789ADE4D9E3ABB6B03E18F9@AMERWEST-EMS1.IONAGLOBAL.COM>
To: "Assaf Arkin" <arkin@intalio.com>
Cc: <public-ws-chor@w3.org>


>> <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:20:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:06 GMT