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
|