[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 162 - discussion
Hi all, [A] +1 to about clarifying the text, generally speaking. [B] But, I got some further questions. Do we really intend to rule out these two cases: case (1): --------------------------- <scope> <sequence> <receive name="recvQuotation" ... /> <receive name="recvQuotation" ... /> </sequence> </scope> --------------------------- case (2): --------------------------- <scope> <sequence> <while ... > <sequence> <receive name="recvQuotation" ... /> </sequence> </while> <receive name="recvQuotation" ... /> </sequence> </scope> --------------------------- Current text seems to rule out both cases. For just compensation logic, neither case does not need to be ruled out. I am OK to rule out case (1). Because, we can have a "name-path" concept to uniquely point to an activity in BPEL code. I am not sure it is a good idea to rule out case (2). It may be too inflexible to users. It may put too much burden to come up with a unique name for all activities in a large scope. At the same time, I don't see any benefits for this kind of restriction. [C] For the compensation logic, the minimal unique naming restriction can be expressed as follow: All child scopes within a scope, including all scope-equivalent constructs (e.g. a special variant of <invoke> with a faultHandler or compensationHandler), MUST have a unique name, if those child scopes are not anonymous. IMHO, the "child" word as in "parent-and-child" already implies the semantics of "not within a nested scope". If we want to rule out case (1) or even case (2), I would suggest express that restriction in other section, since that restriction is not related to compensation and its scope-unique-ness requirement at all. Also, the original wording seems to be implied every activity or scope MUST be named all the time, i.e., we cannot have anonymous activity at all? I hope this make senses to you guys. And, the new wording sound more "crisp" and precise. If needed, we may want to reopen the issue and pass the new text. Thanks! Regards, Alex Yiu Danny van der Rijn wrote: Yes, a combination of the 2 statements would probably be best, as you point out: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]