OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 229 - Proposal for vote


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]