This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Test ---- Test group: UseCases/PartsUpdates Test query: parts-q3-2.xq Problem ------- The query does not pass pessimistic static typing because the parameter in the function declaration of local:delete-subtree is typed as 'element(part)'. When static typing is supported this results in a XPTY0004 which is currently not accepted as a valid result. Resolution ---------- There are two possible solutions, or we add XPTY0004 as an acceptable error code to the catalog, or we change the parameter from 'element(part)' to 'element(part, xs:untyped)'
I'm seeing this differently than you are. The query in question is: declare updating function local:delete-subtree($p as element(part)) { for $child in $part-list//part where $p/@partid eq $child/@partof return ( local:delete-subtree($child), delete node $child ) }; local:delete-subtree($part-list//part[@name="car"]) I'm guessing that the inferred type of the expression in the initial invocation of delete-subtree, element(part)*, is the problem. This does not match the declared type of the parameter. I'd suggest fixing this by changing the function definition to: declare updating function local:delete-subtree($p as element(part)*) { for $child in $part-list//part where $p/@partid = $child/@partof return ( local:delete-subtree($child), delete node $child ) }; If you agree, then I'll make the change and then file this as a bug against the Update Facility Use Cases.
Please disregard my response in comment #1. I was confused by a mismatch between the query in the test suite: local:delete-subtree($part-list//part[@name="car"]) and the query in the Use Cases document: for $p in doc("part-list.xml")//part[@name="car"] return local:delete-subtree($p) I've updated the test suite to bring them into sync. I've reported your concern about the type of the $p parameter in Bug #6288.
The Working Group discussed this issue at its meeting today. We concluded that after Andrew's change (reported in comment #2) to the test case query, it now passes static type analysis. However, this change deals with cardinality, whereas your proposed solution deals with type annotations, so it seems unlikely that we have addressed your original concern. If you think the amended query still fails static type analysis, please provide more details as to why. (By the way, 'element(part,xs:untyped)' is a strict subtype of 'element(part)', so it would seem that the only effect (if any) of changing the parameter type as you suggest would be to *introduce* a type error, not remove it.)
To answer the question in comment #3: "If you think the amended query still fails static type analysis, please provide more details as to why." In the end this is similar to bug #2104 - the parameter $p is declared as "element(part)". - $p/@partid is typed as attribute(partid, xs:anySimpleType)* (similar for $child/@partof) - As a consequence, $p/@partid eq $child/@partof can statically compare incompatible types and should raise XPTY0004. As such we see two options a) adding XPTY0004 as a valid result b) declaring the parameter as element(part, xs:untyped), will make the eq-comparison pass the static typing rules (This second alternative is obviously only viable assuming that the input document is "untyped"
Thank you for claifying things in comment #4. I now agree with the problem you raised initially: an XQuery implementation supporting the Static Typing Feature (without type extensions) would be required to raise err:XPTY0004 during the static analysis phase, in respect of the expression $p/@partid eq $child/@partof in XQUTS test case parts-q3-2. Sorry for not recognizing that earlier in the discussion.
At its meeting on January 27th, the XQuery WG decided to resolve the bug by leaving the query as is, and adding XPTY0004 as an expected result for the test case. Consequently, we are marking this issue as resolved-FIXED. If you agree with this resolution, please mark it CLOSED.
We agree with this resolution. Closing the issue.
The changes to the test suite have been checked into CVS.