This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following function declarations contain parameters without a declared type. 5.15 of the Formal Semantics states these are given the item()* sequence type. But the functions expect them to be a different type. For example, in function-declaration-006: declare function local:mysum($i, $j) { let $j := $i + $j return $j }; This does not type check as $i + $j expectes anyAtomicType? Could these functions be modified to define types for the parameters. function-declaration-003 function-declaration-005 function-declaration-006 function-declaration-017
Same issues in default_namespace-003 default_namespace-005 default_namespace-006 default_namespace-016 default_namespace-017
Nick: Thanks for the comment. I changed the tests to add types for the arguments. However no change was made to default_namespace-016 as I do not see the static typing issue. Thanks, Carmelo
We are currently throwing a err:XPTY0018 "a type error if the result of the last step in a path expression contains both nodes and atomic values." during static type checking. What happens is, because it has no return type, the function title type checks with a return type item()*. item()* can contain both nodes and anyAtomicTypes, so when we static type check the path expression we throw the XPTY0018 as the type is not a node sequence or an atomimc type sequence. Looking through the spec again I can't at the moment find anything specifying this check should we done during static typing rather than evaluation, so maybe it is just us being too zealous in the static type checking.
I agree default_namespace-016 has a type error, but I don't think it's XPTY0018. XPTY0018 is raised when the last step contains a mixture. The last step in default_namespace-016 has type item()*. It's hasn't been proven that it contains a mixture of items. A mixture of nodes and atomic values is one possible instance of item()*, but so is only nodes and only atomic values as well. I believe XPTY0004 is the correct error to raise because currently the query can't be statically type checked in a sound way. I suggest fixing the test by adding XPTY0004 as an alternative baseline.
Frans/Nick: Al lgood points, but by looking at the test, the purpose of it is not to throw an error at all. What if we change the fucntion to return element(), This should take care of those static typing issues. Carmelo
Yep. Adding a return type to the function would be a good solution. But I think the return type will need to be element()* or an exactly-one(...) will need to be added to the body of the function.
Nick: Agreed. Changed and submitted changes as suggested (added "element()*") to function's expected value. Please close the bug if in agreement. Thanks, Carmelo
Great. Thanks. Before I close, I don't know if you want this in a different bug report, but there is the same issue in: modules-7 modules-9 modules-10 modules-11 The problem is in the function defined in test1-lib.xq declare function test1:ok () { "ok" }; It should have return type string.
Nick: This is fine. I will look at them today. Carmelo
Nick: Done! Carmelo