Alex Yiu wrote:
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.
Yes, and why shouldn't it be? The only reason that scopes need to be
uniquely named is so that they can be called by named compensation. My
point is that if named compensation isn't called, then the scope name
is useless, and can therefore be allowed to be non-unique.
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
|