3829 2006-10-13 14:36:12 +0000 Static typing of function declarations 2006-12-15 18:42:49 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite 1.0.1 PC Windows XP RESOLVED FIXED P2 normal --- 1 nick carmelo public-qt-comments oldest_to_newest 12433 0 nick 2006-10-13 14:36:12 +0000 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 12437 1 nick 2006-10-13 14:57:04 +0000 Same issues in default_namespace-003 default_namespace-005 default_namespace-006 default_namespace-016 default_namespace-017 13153 2 carmelo 2006-12-12 22:18:43 +0000 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 13166 3 nick 2006-12-13 17:08:15 +0000 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. 13172 4 frans.englich 2006-12-13 18:07:38 +0000 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. 13179 5 carmelo 2006-12-14 15:40:38 +0000 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 13180 6 nick 2006-12-14 16:03:45 +0000 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. 13184 7 carmelo 2006-12-14 18:30:26 +0000 Nick: Agreed. Changed and submitted changes as suggested (added "element()*") to function's expected value. Please close the bug if in agreement. Thanks, Carmelo 13185 8 carmelo 2006-12-14 18:32:58 +0000 Nick: Agreed. Changed and submitted changes as suggested (added "element()*") to function's expected value. Please close the bug if in agreement. Thanks, Carmelo 13203 9 nick 2006-12-15 14:19:42 +0000 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. 13206 10 carmelo 2006-12-15 15:54:09 +0000 Nick: This is fine. I will look at them today. Carmelo 13220 11 carmelo 2006-12-15 18:42:49 +0000 Nick: Done! Carmelo