[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
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:
Some of the true power of XQuery actually are classified into two following aspects:
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:
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:
Function Call in XPath 1.0:
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 isintroduced that doesthings like "and(foo,bar)". No tool in its right mind isgoing to say to theuser 'well you can use the prefix style everywhere in BPELbut this onesingle place, join conditions, where you have to use aninfix "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. arkinTo 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. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]