New Issue: languageExecutionFault (comes with proposal to vote)

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

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?