[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]