Not being an XPath expert, I can't determine the validity of Alex's
claim. That being said, as long as no one disputes it, this seems like
a pretty serious flaw in Chris' proposal. My support qualified by my
ignorance as above.
+1
Alex Yiu wrote:
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
|