1) It's not a "joinCondition" if it makes sense to use it when there
isn't a join - i.e. when there's only one incoming link
2) My proposal is not inconsistent with your statement. It only calls
for a (small) restriction on what the expression may express.
Rania Khalaf wrote:
> isn't it easier for the "lay user" to understand that a join Condition
> will evaluate to whatever the expression evaluates to ?
>
>
> Danny van der Rijn wrote:
>
>> Rania-
>>
>> What you find confusing was my restatement of my desire in order to
>> make it more clear for "lay" users. I was attempting to combine the
>> descriptive with the prescriptive. My descriptive statement appears
>> to be confusing, so I can go back to my original prescriptive
>> statement if you and others find it more acceptable. (This is why I
>> like to leave the wordsmithing to the editors...)
>>
>> An explicit join condition MUST NOT evaluate to false in the case
>> where the status each incoming link is false.
>>
>> Rania Khalaf wrote:
>>
>>>
>>> Hi Danny,
>>>
>>> The semantics as they are now are consistent for any join condition
>>> and any number of links. Why special case to make one have to take
>>> into account for each activity the implicit and explicit join
>>> condition? Doing so just adds confusion.
>>>
>>> Regards,
>>> Rania
>>>
>>>
>>>
>>>
>>>
>>> Danny van der Rijn wrote:
>>>
>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
