In addition, it would put the burden on the BPEL engine to implement
3-state XPath logic, instead of delegating to an XPath engine.
Similarly for any extension expression language.
Danny
Yaron Y. Goland wrote:
> This issue is, in my opinion, a feature request.
>
> The BPEL specification was explicitly defined to put in place a
> control dependency between the source and target of a link. In fact,
> exactly that language is used in section 6.1.
>
> In other words, one of the primary purposes of a link is ordering and
> that ordering applies regardless of the outcome of the join condition.
>
> This issue would have us change that behavior, not because it is
> faulty but because it is inefficient. But that inefficiency was a
> known side effect of the design and was accepted by the designers in
> return for allowing explicitly ordering control.
>
> Therefore there is no bug here per say. Rather there is a desire to
> change a feature to work in a different way. That is a feature request
> and therefore I believe this issue should go through the
> super-majority voting process before being accepted.
>
> Yaron
>
>
> Tony Fletcher wrote:
>
>> This issue has been added to the wsbpel issue list with a status of
>> "received". The status will be changed to "open" if the TC accepts it
>> as identifying a bug in the spec or decides it should be accepted
>> specially. Otherwise it will be closed without further consideration
>> (but will be marked as "Revisitable")
>>
>> The issues list is posted as a Technical Committee document to the
>> OASIS WSBPEL TC pages
>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular
>> basis. The current edition, as a TC document, is the most recent
>> version of the document entitled **in the "Issues" folder of the
>> WSBPEL TC document list
>> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> -
>> the next posting as a TC document will include this issue. The list
>> editor's working copy, which will normally include an issue when it
>> is announced, is available at this constant URL
>> <http://www.choreology.com/external/WS_BPEL_issues_list.html>.
>>
>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>> Issue 189: Eliminate JoinConditions always evaluating only after
>> all source
>> activities are complete
>>
>> *Status:* received
>> *Date added:* 29 Jan 2005
>> *Categories:* State management
>> <file:///C:/Perlscripts/wsbpel_issues30.html#category_state_management>
>> *Date submitted:* 27 January 2005
>> *Submitter:* Prasad Yendluri <mailto:>
>> *Document:* WS-BPEL Working Draft, December, 2004
>> *Description:* The BPEL specification currently requires that a
>> joinCondition on a target activity be evaluated only after all
>> sources activities for the links coming into it are complete, whether
>> or not the the joinCondition calls for it. In situations such as an
>> activity needs only one of its source activities to be complete (as
>> in the case of an implicit-join), it is unnecessary with serious
>> performance implications to require that all source activities must
>> be complete prior to evaluating the join condition.
>>
>> *Submitter's proposal:* The specification must eliminate this
>> built-in inefficiency and facilitate evaluation of joinCondition each
>> time an incoming link has a status change, *as an option* on the
>> joinCondition or as a process/scope level enabler.
>>
>> *Links:* (Note considerable discussion before formal raising of an
>> issue) Prasad Yendluri, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00080.html>
>> Danny van der Rijn, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00081.html>
>> Prasad Yendluri, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00082.html>
>> Dieter Koenig1, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00084.html>
>> Prasad Yendluri, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00087.html>
>> Danny van der Rijn, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00088.html>
>> Prasad Yendluri, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00089.html>
>> Tony Fletcher, 27 Jan 2004
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00090.html>
>> Danny van der Rijn, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00091.html>
>> Prasad Yendluri, 27 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00092.html>
>> Announcement, 29 Jan 2005
>> <http://lists.oasis-open.org/archives/wsbpel/200501/msg00109.html>
>> *Changes:* 29 Jan 2005 - new issue
>>
>> Best Regards,
>>
>> Tony/ /
>>
>> / <http://www.choreology.com/>/
>>
>>
>>
>> Tony Fletcher
>>
>> Technical Advisor
>> Choreology Ltd.
>> 68, Lombard Street, London EC3V 9L J UK
>>
>> Phone:
>>
>>
>> +44 (0) 1473 729537
>>
>> Mobile:
>>
>>
>>
>> +44 (0) 7801 948219//
>>
>> Fax:
>>
>>
>> +44 (0) 870 7390077
>>
>> Web:
>>
>>
>>
>> /www.choreology.com <http://www.choreology.com/>/
>>
>> Cohesions™
>>
>> Business transaction management software for application coordination
>>
>> Work:
>>
>> Home: <mailto:>
>>
>>
>
>
> 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.
>
>
>
