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]


I personally am not wise enough to know what the future will hold. What
languages will replace which other languages. Already we have seen XPATH 1.0
on its way to being superceded by the not completely backwards compatible
XPATH 2.0. Who knows what future languages will be introduced? Rather than
painting ourselves into a corner we can provide the expressionLanguage
attribute and element extension. In so doing we allow whatever extensibility
will be needed in the future in a manner that is well defined.

As for the special limitations of Join Conditions, the spec's duty is to
express those limitations independent of any particular language. By so
doing the onus is placed on those who wish to use new languages inside of
BPEL to demonstrate that their new language can be used in Join Conditions
in a manner that meets the BPEL spec's restrictions.

		Yaron


> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Wednesday, December 10, 2003 8:59 AM
> To: rkhalaf
> Cc: wsbpel@lists.oasis-open.org
> 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/le
> ave_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/le
> ave_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/le
> ave_workgroup.php.
>
>



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