I actually prefer <performDefaultCompensation>, moving away from
"compensate" and highlighting that it is invoking default behavior
rather than a specific action. But I am easy on the name, admitting
that my suggestion is even worse for length ;-)
-----Original Message-----
From: Assaf Arkin [mailto:]
Sent: Thursday, December 15, 2005 3:45 PM
To: Danny van der Rijn
Cc: Satish Thatte; Alex Yiu; ; Dieter
Koenig1; ws bpel tc
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:]
>Sent: Thursday, December 15, 2005 1:00 PM
>To: Danny van der Rijn
>Cc: ; '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:] Sent: Thursday,
>
>
>
>
>
>December 15, 2005 1:22 PM
>To:
>Cc: ; '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,
><> 15.12.2005
>19:08 cc
> "'ws bpel
>tc'"
><> 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:]
>Sent: Thursday, December 15, 2005 3:36 AM
>To: ;
>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
>
>
>
>
>
>
> 14.12.2005
>22:00 cc
> "'ws bpel tc'"
> <>,
>Alex
> Yiu <>
>
>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
