This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Could you please clarify the behaviour of treat as. Consider the query: declare function local:result($values as xs:integer*) { if ( current-date() eq xs:date('2008-12-31') ) then $values[4] else $values[position() lt 4] }; let $input := ( (1, 2, 3, 'four') treat as xs:integer* ) return local:result($input) Is 'treat as' required to check its input argument in one go, or is it permissible to evaluate it as items from its result sequence are used? So in this example, is the query only guaranteed to fail with XPDY0050 on 2008-12-31, or should it always fail?
I believe section 2.3.4 makes this as clear as we can make it: "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. " In this case the processor has no reason to evaluate $input[4] other than to check for a dynamic error, and therefore it is not required to do this evaluation. Michael Kay
Thanks. I thought that this might not be the case here, given that the only purpose of "treat as" is to throw an error.
I am not sure you can defer evaluation of an expression behind function parameters. I know that the formal semantics is not normative for the dynamic semantics, but it does apply the expression before it is passed to the function. So I am not sure whether 2.3.4 applies.
Lazy evaluation of function parameters is an absolutely normal technique in functional programming languages and is essential for good performance. Users expect to be able to write a function like declare function first($seq as item()*) as item() { $seq[1] } and have it behave the same as if they wrote $seq[1] directly.
Ah. Glad I raised this now. I agree that that lazy evaluation of "treat as" can give better performance, but it really did surprise me that it would be permissible here. I thought that: $expr treat as xs:someType* meant that a run time check should be performed to ensure that $expr in its entirety was of type xs:someType*, rather than a check that each _used_ item was of the prime type xs;someType. Tha's really the clarification I was looking for. The former interpretation permits lazy evaluation, while the latter does not. I'd agree with Comment #4 wholeheartedly though.
Tim, The Query Working Group considered this bug report on 20 May 2008. The consensus of the working group was to agree with Michael Kay's analysis in Comment #1. We believe that XQuery Section 2.3.4 permits lazy evaluation of expressions, including "treat as" expressions. We do not believe that any change to the XQuery 1.0 specification is required. If you are satisfied with this resolution, please change the status of this bug report to "Closed." Regards, Don Chamberlin (for the Query Working Group)
Thanks.