Re: [wsbpel] Issue 13 - Updated Proposed Resolution]

[rkhalaf <rkhalaf@watson.ibm.com>]

Hi Alex,

The proposal for issue 13 was to relax the syntax in order to "gear up 
for using other
languages for querying that may have a structured syntax" (quoting from 
the proposed resolution).  It is not to figure out how to explicitly 
deal with XQuery/X; therefore, as Yaron already mentioned the discussion 
below is out of scope for issue 13.

The specification currently forces any expressions to be strings because 
they must be in an attribute, where moving it to an element gives more 
flexibility and makes it easier to   add support for other languages. 
Already the specification lets you choose an expression/query language 
at the top level - so you could make up your own language that only uses 
strings and define some fancy binding/usage and have a  valid process. 
We are just saying that instead now it's an element instead of an 
attribute so the expressions in the language that you choose to use 
don't have to be just strings.  Of course, you may want to just stick 
with the default XPath and you're fine.

I understand your concern about how XQuery/X should be used, and there 
are issues in its use with BPEL as there are with the use of any other 
language. With XPath as the default with clearly defined usage, the 
specification is clear about what you would be able to interoperate 
with.   Working out the issues with any additional expression/query 
languages is open, and orthogonal to this syntactic change.

To clarify further, consider the parallel with WSDL  bindings: the SOAP 
binding was defined in the specification , but one could define ones own 
bindings, publicise them and use them. Example there are the Java and 
EJB bindings used in WSIF.  The same thing would apply here. The 
parallel is that you would not disallow bindings in WSDL just because 
you haven't defined the full bindings to all languages.

Regards,
Rania




Alex Yiu wrote:

>
> Hi, all,
>
> I hope I am not too late to join this discussion. :-)
>
> In general, I am all for bringing the capability of XQuery to the BPEL 
> world. It can potentially do some simple data transformation and 
> merging multiple data documents into one document.
>
> I hope this email may bring a new prospective on how to leverage power 
> of XQuery or other similar languages in BPEL, other than XPath 1.0 or 
> 2.0.
>
> I see the current syntax changes is the first step to allow more 
> generic syntax for Query and Expression Language (from attribute to 
> element).  However, this is just the first step from my viewpoint. 
> There are a lot of not-resolved-yet issues in the semantics space with 
> this inline-oriented proposal. Using this syntax change to introduce 
> XQuery power to BPEL may create more issues. IMHO, we may NOT be ready 
> for it yet.
>
> At the end of this email, I would suggest a potentially cleaner way to 
> introduce XQuery into BPEL.
>
> Unresolved Issues include:
>
>     * Language Binding Issue between BPEL and the
>       target-Query/Expr-language:
>
>         * Variable Binding Issue: how variables in BPEL are exposed
>           into the XQuery world? What is the name of variables? Are
>           variable names shared between BPEL world and XQuery world?
>           Can XQuery handle WSDL 1.1 MessageType directly?
>         * Namespace Sharing Issue: the XQuery language has two styles:
>           human-readable XQuery language and not-so-human readable
>           XQueryX (XML version of XQuery). It would be treated as Text
>           or CData Node in XML for plain XQuery, while XQueryX will
>           wrap around target data element and attribute with
>           <xqx:tagName> and <xqx:attributeName> (unlike the literal
>           style of <from> element in BPEL). One way or the other,
>           there is no easy way to effectivly share XMLNS declaration
>           between BPEL and XQuery world. That sort of defeats the
>           purpose of embedding XQuery syntax directly into BPEL.
>
>
> Some of  the true power of XQuery actually are classified into two 
> following aspects:
>
>     * Result Data Model: The primary Data Model of XQuery is a data
>       sequence. This data sequence length can be unbounded / stream
>       and data items in that sequence can be of same types or
>       different types. BPEL Data Model is much restrictive than that.
>       Hence, there is a mismatch in Data Models. We need to enrich our
>       BPEL Data Model to fully leverage XQuery.
>     * Transform Multiple XML Data Sequence into one single result XML
>       Data Sequence: by just allowing embedding XQuery syntax as
>       element content, we do not define / solve how to refer multiple
>       variables and variable binding issue listed above.
>
>
> Basically, before we resolve the above issues, I don't think we are 
> ready to embed a language, which can be used in a relatively 
> complicated way like XQuery, directly into BPEL. I don't want gives 
> people the illusion all the XQuery binding issues is resolved by just 
> introducing these syntax changes.  Also, I don't want open up this 
> syntax gateway which individual vendors tried to solve the above 
> issues in their proprietary ways. That is a big portability issues.
>
> However, we can still leverage XQuery in BPEL without placing the 
> XQuery or XQueryX syntax directly into a BPEL document. Because, 
> XQuery already allows developers to define a XQuery-based function. 
> That is a more well-defined interface for separating:
>
>     * Syntax
>     * Datatypes
>     * XML namespace
>     * variable namespace
>
> It also encourages better encapsulation and  components reuse. The 
> same XQuery function can be used within BPEL or other XML-related 
> components within same application. If the XQuery logic needs to be 
> used multiple time within the same BPEL or multiple BPEL, they can now 
> be re-used with this function-oriented approach. (On the other hand, 
> the inline-approach would encourage users to copy XQuery fragments 
> everywhere in BPEL)
>
> http://www.w3.org/TR/xquery/#FunctionDeclns
>
> E.g.:
> In an XQuery file:
> --------------------------------------------
>
>declare function local:summary($emps as element(employee)*) 
>   as element(dept)*
>{
>   for $d in fn:distinct-values($emps/deptno)
>   let $e := $emps[deptno = $d]
>   return
>      <dept>
>         <deptno>{$d}</deptno>
>         <headcount> {fn:count($e)} </headcount>
>         <payroll> {fn:sum($e/salary)} </payroll>
>      </dept>
>};
>
> --------------------------------------------
> And, this XQuery file / component is deployed together with the BPEL 
> components in the same application.
>
> In BPEL, we can do the following:
>
> <assign>
>    <from expression="local:summary(myBPELVar)" />
>    <to ... />
> </assign>
> <switch>
>    <case condition="local:total(PO,Discount) > 500">
>        ...
>    </case>
> </switch>
>
> Note:
>
>     * We use "expression" as opposed to "query" here.
>     * The expression / query language does not need to change to
>       XQuery. It can stay with XPath 1.0 or XPath 2.0
>     * This function call business is nothing in XML-world. And, we
>       don't need to reinvent the wheel and invent anything brand-new
>       (e.g. variable binding semantics). We can borrow a lot of
>       definition from other specificiations. E.g.:
>
>         Function Call in XPath 1.0:
>         http://www.w3.org/TR/xpath#section-Function-Calls
>         Function Call in XPath 2.0:
>         http://www.w3.org/TR/xpath20/#id-function-calls
>         Function Call in XQuery 1.0:
>         http://www.w3.org/TR/xquery/#id-function-calls
>
>         Function Declaration in XQuery 1.0:
>         http://www.w3.org/TR/xquery/#FunctionDeclns
>
>     * I would even say, this approach is ALREADY allowed by BPEL
>       implicitly as of today. Because, BPEL allows XPath expression,
>       which in turn allows this kind of function-call already. We just
>       need to make the expression available to assign statement in BPEL.
>     * This function-call approach will allow users to switch the
>       implementation choice of language with minimal impact BPEL
>       document itself. E.g. changing from XQuery 1.0 to XQuery 2.0
>     * The development overhead of this approach is very minimal. One
>       seperate XQuery file for ALL XQuery logic and one extra line of
>       function signature declaration for each XQuery logic.
>
>
>
>
> I hope this proposal make senses to you guys.
>
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
>
> Yaron Goland wrote:
>
>>The question is what will cause the least amount of effort for users? To
>>take an existing language that they are familiar with and routinely use and
>>then create a sub-set of it for use in join-conditions or to create an
>>entirely new language specifically for join conditions and now force users
>>to learn two languages with potentially unrelated and inconsistent syntaxes?
>>
>>I personally favor the former. I also think that if we are to finish this
>>spec in a reasonable amount of time we should avoid creating new query
>>languages.
>>
>>	Just my two cents,
>>
>>		Yaron
>>
>>  
>>
>>>-----Original Message-----
>>>From: Maciej Szefler [mailto:mbs@fivesight.com]
>>>Sent: Wednesday, January 07, 2004 9:55 AM
>>>To: ygoland@bea.com; 'Assaf Arkin'
>>>Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org
>>>Subject: RE: [wsbpel] Issue 13 - Updated Proposed Resolution]
>>>
>>>
>>>Consistency should be reserved for areas where there is some
>>>common domain.
>>>As Assaf points out join conditions have nothing to do with XML node
>>>selection, so why would we try to adopt an expression language aimed
>>>squarely at XML node selection crippling it so that it no
>>>longer does what
>>>it was intended to do? It makes no sense to me. If anything
>>>it makes things
>>>confusing.
>>>
>>>Would a structured XML representation such as "<and><link
>>>name="foo"/<link
>>>name="bar"></and>" satisfy your objection to creating multiple sets of
>>>grammars?
>>>
>>>-maciej
>>>
>>>-----Original Message-----
>>>From: Yaron Goland [mailto:ygoland@bea.com]
>>>Sent: Wednesday, January 07, 2004 10:08 AM
>>>To: 'Assaf Arkin'
>>>Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org
>>>Subject: RE: [wsbpel] Issue 13 - Updated Proposed Resolution]
>>>
>>>This has nothing to do with XML manipulation, this has to do
>>>with the need
>>>to have a consistent expression/query language used
>>>throughout BPEL. If
>>>someone is moving to a new expression/query language for all other
>>>expressions in BPEL they should not be forced to use a different
>>>expression/query language just for join conditions. That is why join
>>>condition must have the same syntax flexibility that is
>>>available to all
>>>other expressions/queries.
>>>
>>>    
>>>
>>>>-----Original Message-----
>>>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>>>Sent: Monday, January 05, 2004 7:00 PM
>>>>To: ygoland@bea.com
>>>>Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org
>>>>Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
>>>>
>>>>
>>>>Yaron Goland wrote:
>>>>
>>>>      
>>>>
>>>>>Imagine a prefix style XML manipulation language is
>>>>>        
>>>>>
>>>>introduced that does
>>>>      
>>>>
>>>>>things like "and(foo,bar)". No tool in its right mind is
>>>>>        
>>>>>
>>>>going to say to the
>>>>      
>>>>
>>>>>user 'well you can use the prefix style everywhere in BPEL
>>>>>        
>>>>>
>>>>but this one
>>>>      
>>>>
>>>>>single place, join conditions, where you have to use an
>>>>>        
>>>>>
>>>>infix "foo and bar"
>>>>      
>>>>
>>>>>style.'
>>>>>
>>>>>
>>>>>        
>>>>>
>>>>You're right.
>>>>
>>>>I've read the spec over and over and over and I still don't
>>>>understand
>>>>what XML manipulation has to do with join conditions. I don't
>>>>see node
>>>>selection, there's no context node or any variable/function
>>>>you can use
>>>>to operate on nodes. No operators are allowed unless they deal with
>>>>binary values. If nodes are non-existent, then where does XML
>>>>manipulation come into play?
>>>>
>>>>So while I agree with the logic you presented, I still fail
>>>>to see how
>>>>it applies to join conditions.
>>>>
>>>>arkin
>>>>
>>>>
>>>>      
>>>>
>>>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.
>>
>>  
>>
>