I
would ask that anyone responding to Alex's e-mail not use Issue 13 in the
subject line.
Issue
13 does not propose the introduction of XQUERY into BPEL. Issue 13 only proposes
to change the query/expression syntax from attributes to elements so that at
some point in the future other languages, such as XQUERY, can be added in.
The TC
has previously discussed the introduction of XQUERY into BPEL and my
understanding of the group's consensus was that the group felt it was
inappropriate to put any references to XQUERY into BPEL because XQUERY will not
be a W3C recommendation by the time BPEL is expected to
ship.
Yaron
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.
|