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] Issue 13 - Updated Proposed Resolution]


+1 on the general notion of allowing queried to be extended to support 
other query languages, with two exceptions.

Join conditions are very restricted in what they can perform and their 
inputs. It's best if we simplify them rather than complicate them 
further, and if you look at the list of restrictions on join conditions, 
it may be impossible to extend those to just about any expression 
language (see issue 28).

I am not fully convienced transition conditions require such complexity 
that they would benefit from such an extension. In fact, in considering 
the use of XQuery, I would recommend the following criteria:

- Does the expression result in one or more nodes or a simple value 
(boolean, duration or time instant in our case)?

If the expression result in one or more nodes, then we should consider 
more capable expression languages, and design accordingly. If the 
expression results in a simple value, I do not see any value to go 
beyond XPath.

Assaf

rkhalaf wrote:

>  The proposal is to replace things with expressions and queries  from 
> being an attribute to being an element. This would affect <from>, <to> 
> , <propertyAlias>, and conditions.  This would gear up for using other 
> languages for querying that may have a structured syntax. An example 
> is the upcoming XQueryX, a proposal for XQuery using XML syntax.   The 
> case for string queries is also shown below.
>
> With elements instead of attributes, we can allow one to override the 
> default query/expression languages locally. The proposal allows for  
> optional query/expressionLanguage attributes on queries and conditions 
> that can locally override the global default.
>
> Current syntax:
>
> <wsbp:from variable="ncname" part="ncname"? query="queryString"?/>
>
> <wsbp:link ... transitionCondition="..." />
> <wsbp:targets joinCondition="...">
> .. the same for switch's case, and the whileCondition
>
> Proposed syntax
>
> <wsbp:from variable="ncname" part="ncname"?>
>  <wsbp:query queryLanguage=".."?> ?      query goes here
>  </wsbp:query>
> </wsbp:from>
>
> For example, an XPath 1.0 query would be encoded:
>
> <wsbp:from variable="ncname" part="ncname"?>
>  <wsbp:query>
>  /shipNotice/ShipNoticeHeader/shipOrderID
>  </wsbp:query>
> </wsbp:from>
>
> Conditions:
>
> <wsbp:source ... >
>      <wsbp:transitionCondition 
> expressionLanguage=".."?>...</transitionCondition>?
> </wsbp:source>
>
> and
>
> <wsbp:targets>
>    <wsbp:joinCondition expressionLanguage="..."?>...</joinCondition> ?
>     <wsbp:link.... />
> </wsbp:targets>
>
> .. the same for switch's case, and the whileCondition
>
> his 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. 
>




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