Issue 182 - revising its wordings

Hi, all, 

Regarding to issue 182: 

The issue description was formulated before the F2F discussion in NY.

After the discussion, I feel I should generalize the description to
accomodate a wider range of proposed solutions.

==========================================

Issue Subject: How to add bodies later to BPEL faults without
breaking BPEL code written assuming there is no fault body?

Description: 

According to our current fault matching rules IF a fault has a body
THEN it can only be three ways - by a catch that specifies the name and
body, by a catch that just specifies the body or by catch all. But
notice what can't catch it, a catch that just catches on the name.

That means, if someone needs to add a data body to the fault
later (to add optional interesting data) then all existing catches will
be broken.

How do we make it possible for people to
later add bodies to BPEL faults without breaking BPEL code written
assuming there is no fault body?

Please note that this problem already affect us on BPEL standard
faults. We define BPEL standard faults with their name but without
their bodies. If an implementation decides to introduce extra fault
information in the body later, all existing fault handlers for that
fault will not work. We need to ask users to change their fault
handlers or add new fault handlers. 

Proposed Solution: 

(A) allow <catch faultName="qname"> to catch with fault data
body as well ?

(B) introduce a standard fault body that is thrown with all BPEL
standard faults. And, the fault body will contain an xsd:any ?

(C) add new version of <catch> fault handler that specifies both
a name and a body and can catch either just on name or on both name and
body ?

(D) Other ideas .... ?

==========================================

Thanks!

*** Peter, sorry for the inconvenience caused.

Regards,

Alex Yiu