[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 229 - Proposal for vote
Hi Danny and Assaf, I also like to get something shorter. Maybe "compensateChildren" or "compensateInner" ? I have some neutral (not-so-warm) feeling for "compensateAll". Because it may cause its own confusion. People may think "All" cover the scopes of state other than completed (e.g. running and faulted) Another typical confusion of <compensate /> that I have seen so far is: people (including some TC people) thought it would invoke the <compensationHandler> of the same scope level ... It would be nice to highlight the "child" or "inner" nature of the new name. Thanks! Regards, Alex Yiu Assaf Arkin wrote: > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]