It would be great if we could throw in some clarifying text/definition
somewhere. And then we could ignore my specific issue with 162.
Danny
Prasad Yendluri wrote:
Folks,
As we agreed in the f2f yesterday, we will add back the clarifying text
in parens, like "All
scopes and activities directly nested in a
scope (i.e.
not within a nested scope) MUST
be uniquely named.", to 162 text in the spec.
I wanted to note however that upon my review of the spec, I noticed
that it currently uses the phraseology "directly nested" to mean the
above, without the clarifying text as above (some of it going all the
way back to the original BPEL 1.1 version). I cite a couple of examples
below:
1. Section 13.4.2
"Definition:
Peer-Scopes.
Two scopes S1 and S2 are said to be peer
scopes if they are both directly nested within the same scope
(including process scope). "
2. Section 12.6
"a
flow activity creates a set of concurrent
activities directly nested within it."
3. 13.3.3
"a
fault or compensation handler attached to
scope S causes the default-order invocation of compensation handlers
for
completed scopes directly nested within S. "
As info..
Regards,
Prasad
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
|