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] Dead Path Elimination and Join Conditions

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

             Danny van der                                                 
             <dannyv@tibco.com                                          To 
             >                         Dieter Koenig1/Germany/IBM@IBMDE    
             27.01.2005 19:51          andrew.francis@mail.mcgill.ca,      
                                       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.


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

>             Danny van der

>             Rijn

>             <dannyv@tibco.com                                          To

>             >                         andrew.francis@mail.mcgill.ca

>                                                                        cc

>             26.01.2005 22:23          wsbpel@lists.oasis-open.org

>                                                                   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 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.
>andrew.francis@mail.mcgill.ca 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


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]