[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 229 - Proposal for vote
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]