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
>
>
>
>
