[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 13 - Updated Proposed Resolution]
When the conversation reaches a point where proposals for the introduction of new languages are being made then I think it's time to call 'time'. Simplicity is best served through consistency. Rania's proposal provides a consistent way to deal with all expressions in BPEL, including join conditions. Rather than increasing complexity through inconsistency let's just adopt Rania's proposal in full. Yaron > -----Original Message----- > From: Assaf Arkin [mailto:arkin@intalio.com] > Sent: Monday, December 22, 2003 6:29 PM > To: ygoland@bea.com > Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org > Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution] > > > Yaron Goland wrote: > > >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. > > > > > Since it boils down to flexibility vs simplicitly, I feel comfortable > with a choice that gives me more flexibility in some places and more > simplicitly in others, based on what I perceive the usage patterns to > be. If I cannot support any expression language in assignments, then > flexibility gets hindered. If I can support any expression > language in > assignments, I don't have a problem restricting expressions > in other places. > > >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. > > > > > That's one way to solve the problem. Which requires that we > express the > restrictions in a very generic way, and then write how they > are met by > at least one expression language (say XPath 1.0), and then keep doing > that for every other language we want to support. But seeing > that join > expressions are nothing more than binary expressions on link > status, one > could easily devise a simple language for just such > expressions. It seem > to me that this will be the most efficient path to meeting our > requirements. I don't see why we need all the complication of > multiple > expression language support just so we can say 'linkA and not(linkB)'. > > Assaf > > > 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. > >> > >> > >> > >> > > > > > >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. > > > > > > > -- > "Those who can, do; those who can't, make screenshots" > > ---------------------------------------------------------------------- > Assaf Arkin arkin@intalio.com > Intalio Inc. www.intalio.com > The Business Process Management Company (650) 577 4700 > > > This message is intended only for the use of the Addressee and > may contain information that is PRIVILEGED and CONFIDENTIAL. > If you are not the intended recipient, dissemination of this > communication is prohibited. If you have received this communication > in error, please erase all copies of the message and its attachments > and notify us immediately. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]