[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 229 - Proposal for vote
Hi Dieter, I am not sure which text you are suggesting to replace (or add to) with this text. Is it the same text as Alex is suggesting to change? Thanks, Chris -----Original Message----- From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] Sent: Thursday, December 15, 2005 3:36 AM To: alex.yiu@oracle.com; chris.keller@active-endpoints.com Cc: 'ws bpel tc' Subject: Re: [wsbpel] Issue 229 - Proposal for vote +1 Here is one more ...: User-defined fault handlers, compensation handlers, or termination handlers may use <compensate scope="..."> to compensate a specific child scope and/or <compensate/> to compensate all child scopes in default order. Any repeated attempt to compensate an individual child scope is treated as a no-op. Kind Regards DK Alex Yiu <alex.yiu@oracle. com> To chris.keller@active-endpoints.com 14.12.2005 22:00 cc "'ws bpel tc'" <wsbpel@lists.oasis-open.org>, Alex Yiu <alex.yiu@oracle.com> Subject Re: [wsbpel] Issue 229 - Proposal for vote Hi Chris, Thank you again for sending the proposal out. I am for general direction of this proposal. "Explicit invocation of compensation for such a scope nested within S effectively removes the scope from the default-order compensation, but the remainder of the compensation order is preserved. If a <compensate/> is used prior to a <compensate scope="Sx"/> the latter is treated as a no-op" Technically, what your text describe is consistent with my understanding and preference. However the wording of "effectively removes" make me worry this text gives people an impression that the default-order compensation is mutable upon <compensate scope="Sx" />. In fact, we have no mechanism to change the default-order. Thinking out loud here ... how about: "After any explicit invocation of compensation for such a scope nested within S, the default-order compensation is still available via <compensate/> activity. During the default-order compensation, any attempt to compensate a scope which has been already explicity compensated is a no-op. On the other hand, if a <compensate/> is used prior to a <compensate scope="Sx"/> the latter is treated as a no-op" I guess it will have less room of misunderstanding. What do you think? Thanks! Regards, Alex Yiu Chris Keller wrote: Issue 229 Proposal Summary: Allow <compensate/> after <compensate scope="Sx"/> and emphasize that user defined fault and compensation handlers must explicitly call compensate for child scope compensation to occur. Changes to current specification -------------------------------- Section 13.3.3 "...Note that the <compensate/> activity in a fault or compensation handler attached to scope S causes the default-order invocation of compensation handlers for completed scopes directly nested within S. The use of this activity can be mixed with any other user-specified behavior except the explicit invocation of <compensate scope="Sx"/> for scope Sx nested directly within S. Explicit invocation of compensation for such a scope nested within S disables the availability of default-order compensation, as expected." Change to: "...Note that the <compensate/> activity in a fault or compensation handler attached to scope S causes the default-order invocation of compensation handlers for completed scopes directly nested within S. The use of this activity can be mixed with any other user-specified behavior including the explicit invocation of <compensate scope="Sx"/> for scope Sx nested directly within S. Explicit invocation of compensation for such a scope nested within S effectively removes the scope from the default-order compensation, but the remainder of the compensation order is preserved. If a <compensate/> is used prior to a <compensate scope="Sx"/> the latter is treated as a no-op. The compensate activity MUST be used by user defined fault handlers and compensation handlers for child scope compensation to be called. If a user defined fault handler or compensation handler does not use the compensate activity child scopes will not be compensated." Section 14.6 --- Remove this section as it is not applicable per issue 209 resolution --- Appendix A - --- Remove repeatedCompensation fault as it is not applicable per issue 209 resolution --- --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]