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]


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