[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 163 - Proposal For Vote
I lost this issue in the shuffle somehow. Thanks to Yaron for being on
the other side of the whip. Please accept my submitted proposal as
such (deleting/ignoring the question).|
Peter Furniss wrote:
Now submitted as 163, with status "received". It is presumably open to the TC to accept this as a bug, treat Danny's solution as a proposed resolution to the then open issue, and agree the resolution in a matter of 5 minutes, since the f-t-f is quorate. Peter-----Original Message----- From: Danny van der Rijn [mailto:email@example.com] Sent: 22 September 2004 01:52 To: Furniss, Peter Cc: firstname.lastname@example.org Subject: New Issue: languageExecutionFault (comes with proposal to vote) This issue came up during our F2F discussion of issue 89 today. Note that I sent it to Peter as per our process, so that it can get assigned an issue number. However, it was mentioned today that we might want to accept it and deal with it during our meeting tomorrow, so Peter may not have dealt with it yet. So I am cc-ing the list in case Peter's process doesn't assign it a number and resend to the list by the time we want to deal with it. I imagine that it would probably aid the issues list if any email discussion on it were held off until the issue number were assigned. Discussion: If a language that is executing subordinate to BPEL (e.g. XPATH) throws a fault, there is no current spec language that defines what to do with it. This proposal clarifies that behavior. Proposal: To add a new standard fault, languageExecutionFault, which is thrown if the expression language or xxx throws an unhandled fault. Add to the end of section 14.1 "If execution of the expression language yields an unhandled fault, the standard fault languageExecutionFault is thrown. Add to the end of section 14.3 "If execution of the query language yields an unhandled fault, the standard fault languageExecutionFault is thrown. Question: Should this fault define a message type (or should a generic message type be defined) to carry any additional data that is received from the executing language?