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



Hi Danny,


Danny wrote:
The only time that the naming needs to be unique is if named compensation is called.
Completely agree with you. That's why I said the current text (or the resolution text) is too restrictive with no good reasons behind it.

So the minimal requirement we could have is:

    If named compensation is called, then the activity to be compensated MUST be unambiguous.  This requirement MUST be statically enforced.


I agree with the spirit behind your language. It is a bit too loose. It seems to me that if <compensate scope="S" /> is not used, then the scope "S" can be used twice within the same parent scope.

That's why I prefer something along the text suggested in my last email. That seems more precise?

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, when those child scopes are not anonymous.

Thanks!


Regards,
Alex Yiu



Danny van der Rijn wrote:
I would be fine with both case 1 and case 2, but that's not what we currently have.  the "name-path" concept isn't part of the spec, as far as I can tell, but it doesn't need to be, either.

The only time that the naming needs to be unique is if named compensation is called.  So the minimal requirement we could have is:

    If named compensation is called, then the activity to be compensated MUST be unambiguous.  This requirement MUST be statically enforced.

If we're going to change 162, I'd like to see some justification for getting any stronger than the above.

Danny

Alex Yiu wrote:

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:

All scopes and activities within a scope which are not within a nested scope MUST be uniquely named.

Prasad Yendluri wrote:
Danny,

Are you asking that the clarification that was in the parenthesis "(ie, not within another nested scope)" be added, to make things clear? 

Regards,
Prasad

Danny van der Rijn wrote:
Just going through (parts of) the spec again, and I found that the wording that ended up in the spec for 162 (13.3, 3rd para from the end):

"All scopes and activities directly nested in a scope MUST be uniquely named."

Is not as clear as in the issues list.  (Note that I can't find this text in any email, only in the issues list).

"
The names of all activities directly nested (ie, not within another nested scope) within a scope will be unique."

May I ask the editors to update the spec with the issues list language?  It seems much clearer to me in a way that isn't obvious otherwise.


Dieter Koenig1 wrote:
Issue 162 - Unique Activity Names for Compensate

Proposal: Add text to section 13.3.3 "Invoking a Compensation Handler" to
clarify that activity names used in a compensate activity must be unique
within the scope.

Rationale: Currently, there is no constraint on activity names, i.e. the
activity name (standard attribute) does not have to be unique. As a result,
a compensate activity may become ambigous:
    scope
        compensationHandler
            compensate "A" <-- don't know which one
        scope name="A" <-- first enclosed scope
        scope name="A" <-- second enclosed scope


Kind Regards
DK


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.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]