27392 2014-11-21 16:07:31 +0000 Type checking of functions 2014-11-22 10:57:26 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.1 Working drafts PC Windows NT RESOLVED WONTFIX P2 normal --- 1 christian.gruen jonathan.robie mike public-qt-comments oldest_to_newest 115299 0 christian.gruen 2014-11-21 16:07:31 +0000 Section 2.3.4 Errors and Optimization of the XQuery 3.1 spec says that: "The effect of these rules is that the processor is free to stop examining further items in a sequence as soon as it can establish that further items would not affect the result except possibly by causing an error. For example, the processor may return true as the result of the expression S1 = S2 as soon as it finds a pair of equal values from the two sequences." This is currently specified at the level of expressions, but I have not found a clear hint if it can also be applied to type checks. See the following example: function() as xs:integer+ { 1 to 100000, <x/> }() = 1 This query could be rewritten to (something similar like) the following expression, and it would yield true (provided that a processor evaluates the query in a streaming manner): (1 to 100000, <x/>) ! (. treat as xs:integer) = 1 Another example: Strict type checks would prevent a query processor from streaming results of functions if the return type cannot be statically determined: function($x) as xs:integer+ { 1 to 1000000000, $x }(123)[1] As the examples indicate, I would clearly be in favor of allowing iterative type checking. 115302 1 mike 2014-11-21 16:48:44 +0000 The errors and optimization section is far from perfect and will never be so unless we can find some new formalisms, but I think the optimizations you describe are clearly allowed (and widespread in current products, judging by the feedback we get on test cases). The rule is the processor is free to stop examining further items in a sequence as soon as it can establish that further items would not affect the result except possibly by causing an error and that is what you are doing. The only exception to the above rule is the requirement to do cardinality checks. This is because it would have licensed the XPath 1.0 behavior of allowing things like contains(AUTHOR, "Mike") where all but the first AUTHOR are ignored, and the XQuery WG had already decided it didn't like that feature of XPath 1.0. 115354 2 christian.gruen 2014-11-22 10:57:26 +0000 Thanks, Michael. I am marking this as resolved.