[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
I believe this will be ill convienced. It may be more benefical to look beyond the fact that all these expressions use the word 'expression', inspect the obviously fundamental differences in what they capture and how they are used, and perhaps we'll reach a different conclusion. Assaf Yaron Goland wrote: >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. >> >> >> >> > > >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. > > -- "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]