[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 11 - why <copy create="yes"> is instrincally interwinedwith XPath
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:
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:
<def id="d1"> <ghi id="g1"> </def>
<def id="d2"> <ghi id="g2"> </def>
/abc/def/ghi points to "g1"
/abc/def/ghi points to "g2"
Now, if someone tries to use this "create" feature to copy to "/abc/def/ghi", 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" => "/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.
"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"? As long as "/abc//def" returns one elment node?
For (3), is this Xpath "/abc/def/ghi[@abc='fff']" supported? How about "/abc/def[@abc='fff']/ghi"? 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.