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