[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issues Regarding XQUERY
Hi Alex,
I have the feeling that most if this discussion is out of scope not only of
issue 13 but of this TC. We already have a way to use XPath 1.0 and that is
what solves the interop problem. Whether people will define the XQuery
binding in one way or another is something that we are not chartered to
solve; someone else should deal with this. Our only concern should be to
make sure the language does not disallow things that people could very
reasonably want to do, like for instance to in-line other query languages
different from XPath 1.0 (this is something you evidently don't dispute.)
That is just what the proposed resolution to issue 13 is trying to do: make
sure we don't close that door.
I suggest we clearly separate the problem you are presenting from issue 13,
as Yaron has already suggested. This discussion does not seem to be adding
much clarity to the debate. I think we should vote on issue 13 as proposed
by Rania and leave further the problem of how to best bind XQuery out of
the TC discussions.
Regards,
Paco
Alex Yiu
<alex.yiu@oracle. To: ygoland@bea.com
com> cc: wsbpel@lists.oasis-open.org, "'Maciej Szefler'" <mbs@fivesight.com>, "'Assaf Arkin'"
<arkin@intalio.com>, "'rkhalaf'" <rkhalaf@watson.ibm.com>, ALEX.YIU@oracle.com
01/12/2004 07:37 Subject: Re: [wsbpel] Issues Regarding XQUERY
PM
Hi,
Don't get me wrong. :-)
We are NOT heading to IDL or CORBA path at all.
Let me clarify and emphasizes some technical points here:
Part [A]:
This function-call facility already exists in XPath 1.0, XPath 2.0
and XQuery 1.0 specification. Unless we explicitly exclude the usage
of this facility in our default XPath 1.0 dependency, BPEL spec would
need to deal with the semantics of function call in XPath 1.0
already. The interop between XPath, XQuery and XSLT will happen no
matter how BPEL decides to take in a language like XQuery.
And, this function-call approach is nowhere close to the complexity
of IDL/CORBA. Because, the implementation language must share the
same type system (XML Schema). There is no IDL-to-Java or IDL-to-C++
type mapping business. Also, there is NO security, distributed,
object-oriented aspects of this function approach.
And, we are NOT calling for a universal IDL-like interface. If a
language say (e.g. APL :-) ) does not know how to talk XML and XML
Schema, they will not be plugged into XPath or BPEL.
[ If function-call approach was heading the IDL path, the inline
approach would be heading to even a more complicated path - "IDL +
SQLJ-like-PreCompiler" path. :-) ]
Part [B]:
The semantics of function call in XPath 1.0 or XPath 2.0 and its
interactions with BPEL side of world is quite simple. And, we need to
define it anyway, unless we exclude function call usage in our XPath
dependency. Here are the semantics we need to define:
Pass-by-value: the parameters are passed into the function in
the pass-by-value manner. (Hence, no serializable or concurrent
complications)
Variable namespace: The variable name used to passed parameters
into the function shares the same namespace of the current
variable scope of BPEL. And, the function implementation (e.g.
XQuery) would have its own variable namespace. (That is very
natural and intuitive, IMHO.)
[That is all that I can think of so far.]
Part [C]:
Just finished a brief chat with one of Oracle's W3C representatives
(Karun K), he mentioned some very important points:
Assignment Semantics:
XQuery is using assignment by construction model. The
"let" assignment clause will not actually modify the
existing variable during the assignment, it will actually
create a new variable and refering to the new copy of
variable (similar to java.lang.String situation)
BPEL is using assignment by destruction model. The
<assign> element will actually modify the existing
variable value. (Even though the BPEL spec does not spell
it out explicitly, the serialiableVariableAccess
attribute in the scope element implies that already).
How to combining two assignment semantics in one document
in the inline approach is not obvious. Even after we
spell out how to combine them, the inline syntax can be
potentially confusing to users. E.g.
<flow>
...
<sequence>
<assign>
<from ... /> <to variable="PO" />
</assign>
...
<invoke ... outputVariable="PO" />
</sequence>
...
<sequence>
<assign>
<from ... >
<query>
for $i in ...
let $PO := ...
...
</query>
</from>
<to variable="customer" >
</assign>
</sequence>
...
</flow>
What is the mutation semantics of "PO" in the above
example?
I hope you can see by now the inline approach is actually
more complicated and potentially confusing than
function-call approach.
XQuery Syntax: Plain XQuery syntax is not that "embeddable"
into an XML Document, as it will be embedded as a text/CData.
On the other hand, XQueryX can be XML Element subtree
embeddable into an XML Document. However, it is not
human-readable at all and it still have other XMLNS declaration
sharing issues. So, not ideal for being embedded into an XML
Document either. There is some discussion that there MIGHT be a
3rd kind of syntax which is in between plain XQuery and XQueryX
. Hopefully that fits more into the role being embedded into an
XML document.
Part [D]:
I am NOT against the inline approach in a longer term. What I
suggested is to let us leverage the existing function-call approach
FIRST, which is more well defined and more ready to be plugged-in
another programming language. We can wait-and-see for the inline
approach.
When we are ready to inline another language (similar to XQuery), I
prefer doing relaxation of the syntax (from attribute to element) and
resolving variable binding and other semantic issues in one release.
What I want to avoid is: release the syntax in one version of BPEL
spec without specifying how to bind inline another programming
language (similar to XQuery 1.0) explicitly in a normative appendix
in the same version of the BPEL spec. That is a HUGE portability
issue. If our deadline for BPEL 1.1 spec production is mid of 2004, I
prefer relaxing the syntax for inlining and defining the binding in
one shot in next version of BPEL spec to be in sync with XQuery 1.0
production or even the new kind of more-embeddable XQuery syntax.
Hope all these make senses to you guys.
Thanks!!!
Regards,
Alex Yiu
Yaron Goland wrote:
XML in, XML out, sounds easy. But the call for a universal interface
between languages based on a standard IDL is an old one. I would
respectfully suggest that re-inventing Corba is out of scope for the
BPEL TC.
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Thursday, January 08, 2004 12:53 PM
To: ygoland@bea.com
Cc: wsbpel@lists.oasis-open.org; 'Maciej Szefler'; 'Assaf Arkin';
'rkhalaf'; ALEX.YIU@oracle.com
Subject: Re: [wsbpel] Issues Regarding XQUERY
Hi, Yaron,
Thanks for renaming the subject for a better organization of email
threads.
Just want to add a couple of more points for clarification:
Issue 13 is an issue separated from bringing XQuery to BPEL.
However, the syntax change is kind of triggered by the concern
on how to inline a language (similar to XQuery) directly into
BPEL.
I guess when we evaluate whether we need to make a syntax
change as suggested in Issue 13, we may want to use XQuery as
our key language example in the context of brainstorming and
verifying our design and the benefits / complications of new
syntax. Because, if we want to embed other relatively
full-blown programming languages (e.g. ECMAScript) similar to
XQuery, it will share similar implications.
If consensus in BPEL TC leans towards leveraging function-call
approach in XPath (suggested in my previous email), I would say
we may not want to change the syntax for query/expression from
attribute to element *for this BPEL release*, as there may not
be any urgent need for that.
Yes, I think we should have separate email threads for two
discussions. But, I see these two discussions are inter-related in
some ways.
Also, the function-call approach would not create direct dependency
on XQuery either. Note that the same function-call approach would
work for other programming languages, as long as they are XML-capable
in a sense.
Looking forward to further feedback and discussion on Issue 13 and
this email thread regarding to how to bring XQuery into BPEL.
Thanks!
Regards,
Alex Yiu
Yaron Goland wrote:
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
-----Original Message-----
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Wednesday, January 07, 2004 12:44 PM
To: ygoland@bea.com
Cc: 'Maciej Szefler'; 'Assaf Arkin'; 'rkhalaf';
wsbpel@lists.oasis-open.org; ALEX.YIU@oracle.com
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:
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
.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]