Hi, all,
BTW, I did talk to Oracle's XQuery-update W3C rep on last Friday.
I mentioned a number of possibilities in this BPEL issue. This "create"
feature clearly got a thumb-down from our rep.
For other companies who also particpates W3C XQuery-update, you guys
may want to double check with your XQuery-update rep before casting a
"YES" vote to this "create" feature. Therefore, a rush to "yes" or "no"
vote is NOT most appropriate action right now, especially for companies
who contribute XQuery and XQuery-update.
Yaron, regarding to your attempt to come up with an infoset terms to
describe the behavior, I really appreciate that.
I don't think it solves the problem. See more comment inline below ...
Yaron Y. Goland wrote:
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."
[AYIU]: Both description do not cut it.
Two questions:
(1) how do you locate the parent of non-existent EII in the first
place, if one does not specify the "popoff-child-axis" like description
with XPath terms?
(2) Consider this XPath "/abc//def[@id='alpha']/ghi[2]" and this sample
XML data:
<abc>
<def id="alpha">
<ghi>123</ghi>
</def>
<def id="beta">
<ghi>456</ghi>
</def>
</abc>
The second <ghi> should be added right after
<ghi>123</ghi>. But, your infoset description does not fit.
Again, one need some XPath terms to describe the expected behavior.
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.
[AYIU]: Again, another question:
Can we ever support this feature with this XPath:
"/abc/def//ghi[3]"?
I doubt we can. And, do we want to just do hand-waving on what XPath
expression are not supported with this feature ?
Thanks!
Regards,
Alex Yiu
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.
Yaron
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|