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 - compensate activity naming



Hi Alexandre,

[A]
For an XML-savy person or BPEL-savy person, it would not be too difficult to distinguish between <compensate/> and <compensate scope="X"/>. 

But, if one tries to talk about the difference to a customer or a consultant over the phone, then one may find it difficult. For example, I need to say "...  a compensate activity without any scope attribute ..." to orally describe <compensate/>.   ;-)

And, yes, compensation in BPEL is not a trvial concept to explain. But, let us have a different element name. So, it would be easier for us to explain to our audience. :-)

[B]
More unfortunately, even our current spec is also messed up. When we use <compensate/> ambigously, we sometimes mean "a compensate activity without any scope attribute" sometimes just a general compensate activity.

E.g.:
13.5. Event Handlers
"... invocation of compensation handlers using the <compensate/> activity is not permitted. As stated earlier, the <compensate/> activity can only be used in fault and compensation handlers. ... "

That actually refers to a general compensate activity.

To avoid further confusion / mistake in our spec editing or spec reading, I really still think we should move to another activity name for <compensate/> for default compensation.


[C]
Another example of these naming pattern is <throw> vs <rethrow>.  The syntax of the original proposal for "rethrow" is: <throw /> without any attribute. I made an amendment to rename it to <rethrow>. I think that really helps us in our spec text to describe the difference between throw and rethrow. If we had collapsed both features under the same element name, we would have a similar problem in spec text.

[D]
I do agree with your concern about "inner" may imply existence of "outer". So I would prefer "compensateChildScopes" or "compensateChildren".

[E]
Assume we are going for the renaming. We really should use it as an opportunity to clean the spec text at the same time. That is:

"a compensate activity" means both variants of compensation <compensate scope="X" /> and <compensateChildScopes/>.
"a <compensate> activity" means <compensate scope="X" />
"a <compensateChildScopes> activity" means of course <compensateChildScopes/>.


I really hope the current spec text in Section 13.5 convinces people that current activity naming could cause some confusion.


Thanks!


Regards,
Alex Yiu



aalves@bea.com wrote:
Hi,  

This is a minor observation, but I don't find it that confusing to differentiate between <compensate/> and <compensate scope="X"/>.   

I actually think it makes sense to have the same Xml element relate to both forms of compensation, as, after-all, both do deal with compensation of their inner scopes, the latter selectively.  

Compensation is a tricky feature to explain nonetheless, it seems to me that having a more descriptive name won't help that much, hence I am in favor of keeping the simplicity of the single compensate name.  

For example, we don't have a <receiveInOnly/>, <receiveInOut/> instead of just <receive/>. Also <compensateInner/> seems to indicate that there is a <compensateOuter/>.  

Anyway, just my opinion, either way we go is fine with me.  

Sincerely, 



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