[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 229 - Proposal for vote
While we're wordsmithing, "<compensate/> activity" isn't different from <compensate scope="Sx"/> -- they're the same activity. Can we replace it with "a compensate activity with no scope attribute"? Danny Chris Keller wrote: >Hi Dieter, > >Ok, here are the two sets of text. If we adopt your text it didn't seem to >flow right unless it replaces the entire part after the ellipsis, what do >you think. Is it explicit enough? > >- Chris > >End of section 13.3.3 > >Dieter's suggestion: > >"...User defined fault, compensation, 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. > > >The compensate activity should be used by user defined fault, compensation >and termination handlers to invoke child scope compensation. If a user >defined fault, compensation or termination handler does not use the >compensate activity then child scopes will not be compensated." > >Alex's suggestion: > >"...Note that the <compensate/> activity in a fault, compensation or >termination 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. After an explicit invocation of compensation for >such a scope nested within S, the default-order compensation is still >available via the <compensate/> activity. During the default-order >compensation, any attempt to compensate a scope which has already been >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. > >The compensate activity should be used by user defined fault, compensation >and termination handlers to invoke child scope compensation. If a user >defined fault, compensation or termination handler does not use the >compensate activity then child scopes will not be compensated." > > >-----Original Message----- >From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com] >Sent: Thursday, December 15, 2005 1:22 PM >To: chris.keller@active-endpoints.com >Cc: alex.yiu@oracle.com; 'ws bpel tc' >Subject: RE: [wsbpel] Issue 229 - Proposal for vote > >Yes, this is what I had in mind ... >Kind Regards >DK > > > > > "Chris Keller" > <chris.keller@act > ive-endpoints.com To > > Dieter Koenig1/Germany/IBM@IBMDE, > <alex.yiu@oracle.com> > 15.12.2005 19:08 cc > "'ws bpel tc'" > <wsbpel@lists.oasis-open.org> > Please respond to Subject > chris.keller 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 > > > > > > >--------------------------------------------------------------------- >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 > > > > >--------------------------------------------------------------------- >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 > > > > > > >--------------------------------------------------------------------- >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]