OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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

Copy is not currently schema aware in any well defined sense since we 
all agree that the current requirements (the prevent things like copying 
XML values into WSDL messages) are nuts. So arguing that Chris's 
proposal is bad on that basis isn't currently sound. On the other hand 
arguing that we shouldn't pass any proposal on 11 until copy is actually 
properly defined is an argument I can get behind.

Your assertion that this proposal requires XPATH specific behavior does 
not appear to be supported by the facts. For example, your 'popoff' rule 
in infoset terminology becomes "The parent of the EII to be created, 
assuming it is not the document element, MUST have no siblings with the 
same namespace name/local name combination as its own." Although I 
suspect a more appropriate rule might be "The parent of the EII to be 
created, assuming it is not the document element, MUST be the last EII 
in document order amongst its siblings."

I agree, btw, that the XPATH restrictions in the current proposal can 
probably be removed since we can describe the proposals behavior in 
terms of the infoset and so long as the submitted path results in an 
EII/AII whose characteristics match those described in infoset 
terminology then all is fine with the world.

But in any case I don't currently see anything in this proposal or in 
your comments on this proposal that requires XPATH specific behavior.


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:
>           o As the new node will just always be appended to the parent,
>             regardless of the related schema design, as the current proposal
>             stands.
>           o 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]