[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 229 - Proposal for vote
compensateAll? Danny van der Rijn wrote: > Sure. But something shorter, I hope? > > Satish Thatte wrote: > >I remain warm (to the idea I mean). > >-----Original Message----- >From: Alex Yiu [mailto:alex.yiu@oracle.com] >Sent: Thursday, December 15, 2005 1:00 PM >To: Danny van der Rijn >Cc: chris.keller@active-endpoints.com; 'Dieter Koenig1'; 'ws bpel tc'; >Alex Yiu; Satish Thatte >Subject: Re: [wsbpel] Issue 229 - Proposal for vote > > >Hi Danny and others, > >I have been thinking of renaming "<compensate />" activity to something >like "<compensateChildScopes/>" to signal the difference two forms of >compensation and avoid confusion, instead of saying a verbal description > >like "a compensate activity with no scope attribute" > >What do you guys think? >Based on some past email exchange, Satish is warm to that idea. > >If you guys are warm to idea, we could incorporate that into one of >compensation related proposal. That is, to instruct editors to do a >global scan on the term "compensate" in the spec to apply changes >appropriate. [Poor editors ... :-( ... including myself ...] > >Thanks! > > >Regards, >Alex Yiu > > > > > >Danny van der Rijn wrote: > > > >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 > > > > > > > > > >--------------------------------------------------------------------- >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
begin:vcard fn:Assaf Arkin n:Arkin;Assaf org:Intalio adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065 email;internet:arkin@intalio.com title:Chief Architect tel;work:(650) 596-1800 x-mozilla-html:TRUE url:http://www.intalio.com version:2.1 end:vcard
S/MIME Cryptographic Signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]