Alex,
I have shown that one can create a binding
for another queryLanguage, which keeps the basic create operation in tact. Yes,
much of the proposal is for an XPath binding, since the TC is not specifying
the bindings for any other language than XPath that is the only one I describe.
As you mentioned your engine already allows a similar extension, I heard
Bernd say the same thing and yes Active Endpoints engines do as well. If
it is so poor a solution why did 3 companies chose to implement it when they
could have created assign extensions in many other ways? It is because
copy does already do creates at the part level, so the users expect to have
some support at the sub-part level. My fear with Ugo’s proposal is
that it will be shot down. You were not active in the TC when many of the
initial discussions around issue 11 took place and based on those discussions I
think that Ugo’s proposal (which is essentially a recast of a proposal by
Danny about 18 months ago) will not pass.
On your specific questions:
[A] Yes, that is described in a language binding
specific way and would need to be described for another binding. If you
want after this TC is over we can start another to describe a JavaScript
binding.
[B] The reason that predicates are
restricted in the proposal for the XPath binding is that to do generic ones
would lead to ambiguities. For example if you had a query of the form
/abc/def/ghi[@abc=’fff’] would the engine with an element ghi that
had an attribute abc modify abc to be ‘fff’ or create a new one. I
chose to limit the binding to positions only so as to avoid such complications.
[C] You are not referencing current syntax
in your question. Currently a <to> element does not accept a
general expression it accepts a variable, part and a query. But I have
already shown a simple example of a binding for jscript.
I do have a suggestion that we can discuss.
What if we describe the create attribute of query in the namespace of the
XPath binding (I am not sure on what we chose but it is something like http://www.oasis.org/.../xpath1.1).
Then it may be clearer that this queryLanguage handling may be specified in
a different way for other languages.
Regards,
Chris
From: Alex Yiu [mailto:alex.yiu@oracle.com]
Sent: Tuesday, May 10, 2005 12:59
AM
To:
chris.keller@active-endpoints.com
Cc: wsbpel@lists.oasis-open.org;
Alex Yiu
Subject: Re: [wsbpel] Issue 11 -
why <copy create="yes"> is instrincally interwined 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
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 id="d1"> <ghi id="g1">
</def>
<def id="d2"> <ghi id="g2">
</def>
</abc>
/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