Issue 163 - Proposal For Vote

[Danny van der Rijn <dannyv@tibco.com>]

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

Danny

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:dannyv@tibco.com] 
Sent: 22 September 2004 01:52
To: Furniss, Peter
Cc: wsbpel@lists.oasis-open.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?