Right. Change my statement for clarity to the following:
I would prefer that another statement be in the spec that says that an
explicit join condition MUST NOT evaluate to false in any case where
the implicit join condition would evaluate
to true if it existed.
Thanks
Danny
Rania Khalaf wrote:
Hi
Danny,
Each activity has exactly one join condition. So if there is an
explicit join on an activity, there is no implicit one.
Regards,
Rania
Danny van der Rijn wrote:
I agree that the syntax is straighforward.
It appears that we just disagree on the semantics. I would prefer that
another statement be in the spec that says that an explicit join
condition MUST NOT evaluate to false in any case where the implicit
join condition evaluates to true. In other words, it can not be true
when all incoming links are false.
I think it is ugly to have a construct such as a transition that is
meant to express control dependencies, and then allow its use for
expressing "anti-dependencies."
Danny
Dieter Koenig1 wrote:
Hi Danny, I meant *any* join condition, either implicit or explicit.
This applies to *every* activity, either with one or with more
incoming links. This is also how I read the spec:
"(...) propagating negative link status transitively along
entire paths formed by consecutive links until a join condition
is reached that evaluates to true."
"Every activity that is the target of a link has an implicit or
explicit “join condition” associated with it. This applies even
when an activity has exactly one incoming link"
"If the explicit join condition is missing, the implicit
condition requires the status of at least one incoming link
to be positive"
Maybe I am still missing the point, but with these three
statements in the spec, I see no more room for interpretation.
Kind Regards
DK
Danny van
der
Rijn
< To
> Dieter
Koenig1/Germany/IBM@IBMDE
cc 27.01.2005 19:51
,
Subject Re: [wsbpel] Dead Path
Elimination and Join
Conditions
Do you mean that DPE always ends at "an explicit join condition"?
Every
activity in a flow has at least an implicit join condition. While I
agree that an implementation can do what you describe, the especially
pathological case that I describe doesn't even meet the (implied)
semantics of the word "join," since there is only one control path. I
am bothered more by the ability to create extremely confusing semantics
than by any non-implementability.
Danny
Dieter Koenig1 wrote:
Formally, I see no problem as DPE always
ends at a join condition, so the
effect caused by the "SecondToThird" transition is perfectly valid.
Maybe
this is something that should be made more clear in the spec language.
Kind Regards
DK
Danny van der
Rijn
< To
>
cc
26.01.2005 22:23
Subject
Re:
[wsbpel] Dead Path Elimination
and
Join Conditions
The contradiction is one of semantics. There can be no "dead paths" in
such a case, since a join condition later in the path can "resuscitate"
the
path.
The sentinel case you describe can easily be coded differently, say as
the
2nd activity in a sequence, where the first is a flow. After the flow
completes, the sentinel can check conditions. Of course, it can't
check
link status, but I don't see that as a huge obstacle.
Danny
wrote:
Hello Danny:
This is in contradiction with my understanding of
dead-path elimination. I would prefer to disallow
joinConditions whose expression does not require a
true input in order that the join condition evaluate
to true. Comments?
I do not see how your example contradicts sections
12.5.1 (link semantics) or 12.5.2 (dead path elimination)?
I think your example is strange but not pathological.
Let us pretend the programmer does not like fault handlers
and structured the process as a graph with one end activity:
Third. In turn, the programmer wants activity "Third" to
be a sentinel or assert of sorts, executing only if activity
"Second" failed. If my understanding is correct, if "Second"
executes and sets "secondToThird"'s transitionCode to true,
Third's joinCondition will evaluate to false, not run, and
the process is finished: after all nothing bad happened ....
and this is what the programmer intended.
Cheers,
Andrew
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 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 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.
