Hi, Rania and Paco,
Thanks for following up this discussion.
Before going into the discussion again, I would to recap my viewpoint
on this issue again:
---------------------------------------------------------------
There are two cases of resolution:
(1) Leave the spec unchanged. And, we use XPath function call to
incorporate
functionality (like XQuery) for now, as we proposed in previous email.
(2) Relax the syntax WITHOUT defining binding of XQuery (or a similar
language)
in the same BPEL spec cycle.
(1) [new proposal] is simple and easy to understand.
It has ZERO changes and impact to the existing spec.
Fewer language portability issues.
(2) [current proposal] open a flood gate of undefined semantics.
It implies a lot of language portability issues.
---------------------------------------------------------------
I understand that the proposal of Issue 13 is a pure syntax relaxation.
*In theory*, it may look like orthogonal to the semantics of language
binding.
IMHO, opening up syntax without proper semantics examples would be like
openning up a flood gate.
XPath 1.0 is a very simplistic language, compared with XQuery. XPath is
simply used as an one-line expression in BPEL currently. And, it does
not have: assignment or multiple-output semantics.
IMHO, most of programming languages that need to span multiple lines or
multple XML elements (instead of one line of attribute string) will
quite likely have similar features comparable to XQuery: e.g.:
assignment, multiple-output, or even transactional / serializable.
Regarding to the interop , the complexity of binding for a
multiple-line language (e.g. XQuery) is an order of magnitude bigger
than the binding for XPath. XPath binding simply is not rich enough to
provide guidelines for vendor to bind a multiple-line language with
BPEL in a relatively consistent way.
Don't get me wrong. I DON'T want to define binding between BPEL and ALL
languages. It is just we need to have an example of language binding
for BPEL that has
scale of complexity similar to XQuery, not just XPath 1.0, if we decide
to relax the syntax. Then, I
would feel more comfortable about that.
Regarding to WSDL analogy, we have SOAP binding as an example to
illustrate how WSDL can
be bound to a particular protocol. That is prefectly fine. IMHO, SOAP
semantics is rich enough to cover different aspects of WSDL. However,
if the WSDL spec only had an example of SMTP binding without using SOAP
env, then I would feel very uncomfortable about that.
The core issue is: whether XPath 1.0 binding is rich
enough to provide
guidelines for a language of XQuery. I guess the answer is no.
Paco said in one of latest
emails: "leave further the problem of how to best bind XQuery out of
the TC discussions." If that is the direction that we adopt, different
vendors will just have their
proprietary bindings between XQuery and BPEL. I think that would be a
shame for language portability, because both BPEL are XQuery are
standardized, while binding between
them are not portable or standardized.
I hope I can convince you guys and rest of the BPEL community.
Thanks!!!
Regards,
Alex Yiu
rkhalaf wrote:
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.
|