5826 2008-07-02 12:29:39 +0000 parts-q3-2 does not pass static typing 2009-02-06 19:14:03 +0000 1 1 1 Unclassified XQuery Update Facility Test Suite XQuery Update Facility Test Suite unspecified PC Windows XP CLOSED FIXED P2 normal --- 1 Tom.Brosens andrew.eisenberg andrew.eisenberg jmdyck jonathan.robie marc.van.cappellen oldest_to_newest 21017 0 Tom.Brosens 2008-07-02 12:29:39 +0000 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)' 22473 1 andrew.eisenberg 2008-11-19 17:05:36 +0000 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. 22711 2 andrew.eisenberg 2008-12-08 21:35:20 +0000 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. 22776 3 jmdyck 2008-12-16 23:35:16 +0000 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.) 22930 4 marc.van.cappellen 2009-01-05 22:05:05 +0000 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" 23402 5 jmdyck 2009-02-02 23:41:51 +0000 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. 23403 6 jmdyck 2009-02-02 23:45:31 +0000 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. 23437 7 Tom.Brosens 2009-02-04 09:03:38 +0000 We agree with this resolution. Closing the issue. 23540 8 andrew.eisenberg 2009-02-06 19:14:03 +0000 The changes to the test suite have been checked into CVS.