wsbpel message

Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwinedwith XPath

From: Francisco Curbera <curbera@us.ibm.com>
To: Alex Yiu <alex.yiu@oracle.com>
Date: Wed, 11 May 2005 09:32:21 -0400

Alex,

Yaron's last mail shows that you can use infoset terminology to define the
"create=yes" behavior of Chris' proposal, thus putting your claim of XPath
dependency in serious doubt. A good way to cut the amount of "hand waving"
would be for you to answer that argument - going beyond the otherwise
interesting fact that your XQuery reps feel uneasy about the proposal.

Paco

Alex Yiu
<alex.yiu@oracle. To: Francisco Curbera/Watson/IBM@IBMUS
com> cc: chris.keller@active-endpoints.com, wsbpel@lists.oasis-open.org, Alex Yiu
<alex.yiu@oracle.com>
05/10/2005 03:50 Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwined
PM with XPath

Hi,

This "create" feature is defined in the BPEL base spec, not in an
expression-language-specific binding extension specification outside of
this TC.

We MUST provide a clear boundary and direction on how this feature works
with other expression languages by using some pure XML terminologies and
NOT relying terminologies from a particular expression language.

Mentioning a BPEL-base feature in the spec by just showing a definition of
its behavior in XPath ... then hand-waving about what should happen in
other expression languages ... ask implementators to make their own best
guess how this BPEL feature should behave in other expression languages ...
That is just plain violating the fundamental direction of BPEL spec, IMHO.

Paco wrote:
"The fact is that many activities already depend on the use of a query
language, and that usually means that the execution semantics cannot be
fully determine until one language is selected"

Could you actually give some examples to support your claim above?

One key thing to differientiate: "execution details in one expression
language" and "execution semantics of the BPEL" are two different things.

Without knowing which expression language is used, of course, we would not
know the execution details of an expression language after the execution
enters from the BPEL world to the expression language world.

However, the overall execution semantics of BPEL is well-known without
picking a particular expression language, including the pre-condition and
post-condition of executing expression language. (e.g. the post condition
of executing <assign>/<copy>/<to> must always returns on XML node
regardless of which expression language is picked).

As far as I understand, the way that we specify <assign>/<copy> today is
expression language-independent. We define its semantics based on
expression-language terms.

In our definition of <copy> today, we do NOT need to mention: descendants
"//" or predicate "[]", which are the essential parts of this "create"
feature.

(I was trying to mention some political sensitive terms in this email
thread. It seems to me that I have no choice but to touch those hidden
land-mines)

If Paco's claim about the fundamental direction and charter of BPEL TC is
true, then one can define a specific feature which we say only how it works
in Java / BPELJ in this OASIS TC? Leave C# binding for other people to
specify?

For example:
<variable name="x" ... objectType="anObjectClass"? dataBinding="uri"? />
Add an objectType attribute to allow pointing to an Object Class (And in
our spec, we just specify its semantics when it is pointing to a Java
class, do not mention what happen in C#.) And, add "dataBinding" attribute
to point to a XML-to-Object mapping (And, in our spec, we just define what
its means in the JAXB binding world).

Note: I am not saying I am going to define object-features in BPEL. But, if
Paco's claim is true and particularly after passing this "create" proposal,
then we have precedent cases and putting the above definition in BPEL spec
becomes reasonable and legal

Regards,
Alex Yiu

Francisco Curbera wrote:
I think we all understand that binding each query language requires
clarifying many language specific issues; I just don't see how that
argument plays against the "create" proposal. Alex made specific
observations about how the particular XPath binding should be
clarified; I
don't see anything substantial that would prevent the proposal from
being
refined to deal with them.

If, for example, we need to clarify that only XPath expressions that
returns a single node are valid, then, well, we have to do that using
XPath
specific language - I don't get what is the big deal. The fact is
that many
activities already depend on the use of a query language, and that
usually
means that the execution semantics cannot be fully determine until
one
language is selected, even if the overall general behavior of the
activity
is common across languages.

As I sadi before, I think this proposal is our best chance to get
something
reasonable done for issue 11. IMO, the only acceptable alternative
would be
to close with no change.

Paco

Alex Yiu

<alex.yiu@oracle. To:
chris.keller@active-endpoints.com

com> cc:
wsbpel@lists.oasis-open.org, Alex Yiu <alex.yiu@oracle.com>

Subject: Re: [wsbpel]
Issue 11 - why <copy create="yes"> is instrincally interwined
05/10/2005 12:58 with XPath

Chris,

It is of course possible to come up with a similar semantics in some
other
non-XPath languages. (I need to stress that I use the word "similar"
and
"some", not "same" and "all")

But, the question is: How does one come up with one single, portable
and
universal description which is applicable to all programming
languages that
we can think of?

The BPEL base specification MUST provide a universal, clear and
expression-language-independent description to state:
what are the expected behavior of this "create" feature
what expression language patterns are supported and what are
not
supported with this feature.

Without this description, this "create" feature is basically
NON-portable
to other expression language.

For javascript, we basically need to re-describe the semantics in
some sort
of Javascript terminology by saying something like:

getElement(“a”) should return one node, while
getElement(“b”,10)
returns zero node.
[Disclaimer: I am no Javascript expert. My terminologies used
above
are probably wrong. Let me switch to Java and XQuery for other
examples.]

Chris, few questions for you (some of them are already stated in my
previous email) before we move forward:

[A]
How do you resolve "Parent Location Ambiguity" problem that I stated
in my
previous email without referencing to any XPath terminology? How do
you
resolve that problem with an expression-language independent
description?

[B]
Even if we stay within the pure XPath world, it was not clearly
enough
stated that which XPath expression patterns are supported and which
are not
supported. If not supported, why?

Can we support "/abc//def/ghi[3]", as long as "/abc//def" returns one
element node? If not, why?
Do we support "/abc/def/ghi[@abc='fff'][3]"?
Do we support "/abc/def[@abc='fff']/ghi[3]"? If not, why?

And, how do you describe what XPath expression patterns are supported
or
not supported without hardwiring your proposal to XPath terms and
concepts?
And, did you already use quite a few of XPath terms in your proposal
to do
that?

[C]
Instead of covering the infinite universe of programming languages,
could
you come up with a single, universal but clear description to at
least
cover the following cases?

(1) someone uses Java with JAXB embedded within BPEL:
See:
http://java.sun.com/developer/technicalArticles/WebServices/jaxb/index.html

http://java.sun.com/developer/technicalArticles/WebServices/jaxb/CollectionType.java

e.g.:
<to>
javaVariableForCollectionType.getBooks().getBook().get(3)
</to>

How do we say:
"javaVariableForCollectionType.getBooks().getBook().get(3)" return
null
while
javaVariableForCollectionType.getBooks().getBook()" return a non-null
java.util.List object?
WITHOUT referencing to Java terminologies?

(2) someone uses XQuery embedded within BPEL

e.g.:
<to>
{ (for $b in $collectionTypeVar1/book
where $b/price > 200
order by $b/price ) }[3]
</to>

Is the "where" and "order by" clause in XQuery supported, when this
"create" feature is used?

Please note: XPath does not have the order-by capabilities, while
XQuery
has.

Another important note:

NOT All programming languages have the same XML capabilities. Even
within
one programming language, there may be multiple ways to access XML
data.

Example #1: There are other ways to expose XML data in Java other
than
JAXB. How about just pure DOM API?

Example #2: Javascript with E4X extension has more XML capabilites
than the
original javascript.
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-357.pdf

Here is an example of E4X syntax: "order.item.*[1]". Is that
supported?

Thanks!

Regards,
Alex Yiu

Chris Keller wrote:
Hi Alex,

<to variable=”x” part=”y”>
<query create=”yes” queryLanguage=”jscript”>
getElement(“a”).getElement(“b”,10)
</query>
</to>

A context for this script execution would know create was
turned on
and then it would create the 10th element called “b” under “a”
if it
did not exist and return the new “b” element. If create was
not
turned on it could throw a fault.

Thereby the “create” could be applied to a non-xpath language
if the
binding makes it so.

- Chris

From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Monday, May 09, 2005 9:46 PM
To: wsbpel@lists.oasis-open.org
Cc: Alex Yiu
Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is
instrincally interwined with XPath

Hi all,

As I mentioned in the last conf call, here are details on why
<copy
create="yes"> is instrincally interwined with XPath - i.e. no
feasible way to define this feature in an expression-language
independent fashion.

Summary of why <copy create="yes"> is a bad idea:
It is intrinsically XPath dependent (more details are
provided
below), while BPEL itself should be expression language
neutual.
<copy> itself is somewhat schema-aware [See
mismatchedAssignmentFailure], while "create" version of
<copy>
is not:
As the new node will just always be appended to the
parent, regardless of the related schema design, as
the
current proposal stands.
The current form <copy> itself is the pure
replacement
logic, one can compare the XSD type info associated
with
from-node and to-node, when XPath 2.0/XQuery 1.0
data
model is used. If mismatched, it can trigger
mismatchedAssignmentFailure fault. However, for the
"create" version, this feature is lost. That
creates some
hidden and profound asymmetry, which are surprising
to
users.
The create version of <copy> in the standard is NOT
schema-aware, it is almost useless. And, customers
immediately
force vendors to do add sort of schema tricks. It defeats
the
whole point of standardization. It is a very slippery
slope.
Bad for standardization.

Details of XPath-Only / XPath-Dependent Concern

Parent Location Ambiguity

The proposal says: "Newly created nodes are always appended as
the
next child of a parent."
However, it does not address one big ambiguity issue: Where is
the
parent?

Consider this example:

/abc/def/ghi[1] points to "g1"
/abc/def/ghi[2] points to "g2"

Now, if someone tries to use this "create" feature to copy to
"/abc/def/ghi[3]", which <def> is the parent? "d1" or "d2"????

One thing the proposal SHOULD say is: by "popping off" the
bottom-most-XPath-child axis token in XPath expression parse
tree,
(i.e. "/abc/def/ghi[3]" => "/abc/def"), the resultant XPath
expression must be evaluated to be ONE single element node.
Then, it
solves the ambiguity of parent location. This is a MUST-HAVE
clarification.

Please note that: I underlined some of the terms above.
Because,
those terms are extremely XPath specific. This MUST-HAVE
clarification make this feature become completely
XPath-specific.

If one wants to standardize the "create" feature in BPEL spec,
ONE
MUST give the equivalent, crispy clear and portable terms of
underlined text for other expression languages and
data-modeling
technologies. E.g. XQuery 1.0, XPath 2.0, Java (with or without
JAXB
... and with or without SDO), C#, Javascript (with or without
XML
extension), SQL, SQL/XML ... (I consider that
mission-impossible).

"Fuzziness" of XPath Expression Subset Definition

Also, its current attempt to define the subset of XPath
expressions
are supported by this feature is no where clear enough to be
put on
the BPEL spec. As of now, it just tries to excludes 3 cases of
XPath:
(1) must use abbreviation form (2) must not use "//" (3) must
use
position predicate

For (1), the proposal does not provide a real good reason on
why
restricting to abbreviation form only.
For (2), why we cannot support XPath "/abc//def/ghi[3]"? As
long as
"/abc//def" returns one elment node?
For (3), is this Xpath "/abc/def/ghi[@abc='fff'][3]" supported?
How
about "/abc/def[@abc='fff']/ghi[3]"? The proposal does NOT say
it
clearly.

Loosely (or arbitrarily) clipping off some XPath features off
the
support domain does NOT create a portable behavior of this
"create"
feature.

I strongly urge that whoever wants to standardize this feature
(outside of this BPEL TC) should come up with a restricted form
of
EBNF Grammar for XPath expression subset. Then, that grammar
will
clearly state what XPath subset are supported and what are NOT.
That
restricted EBNF Grammar needs to be based on the non-terminal
in EBNF
Grammar of XPath 1.0
(e.g. http://www.w3.org/TR/xpath#predicates )

Implementation experiences say it even louder ...

As I mentioned before, we (Oracle) have a similar
implementation
extension feature. We NEVER have the intention to standardize
this
XPath-only extension feature in BPEL spec. Because BPEL is
supposed
to expression language independent and BPEL spec is NEVER the
right
place to standardize a feature which fudges and breaches the
clean
border line between BPEL and expression language.

That is: The semantics of a BPEL construct (<copy
create="...">)
relies on certain features and behavior of underlying
expression
language. And, we cannot find a proper portable description of
those
features and behaviors across a wide spectrum of expression
languages
that can be put into the BPEL spec.

Also, in our implementation experience of similar features, we
need
to play around with XPath parser implementation to achieve that
functionality. And, that implementation will be NEVER portable
to
other expression languages. That again further illustrates that
this
"create" feature is by definition XPath-concept dependent.

As far as I know some other vendors have similar extension
features
as well, they have no plan to standardize this XPath-only
feature
either. Hence, I am not alone in that crowd.

Thanks!

Regards,
Alex YIu

References:
- Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwinedwith XPath
  - From: Alex Yiu <alex.yiu@oracle.com>