- From: Michael Kay <mhk@mhk.me.uk>
- Date: Fri, 24 Feb 2006 10:23:54 -0000
- To: "'Michael Kay'" <mhk@mhk.me.uk>, "'Per Bothner'" <per@bothner.com>, <www-ql@w3.org>
Given Michael Rys' intervention, I think the debate hinges on which of the following statements takes precedence. 3.1.5: the value returned by a function retains its most specific type, which may be derived from the declared return type of the function. For example, a function that has a declared return type of xs:decimal may in fact return a value of dynamic type xs:integer. (Or more generally 2.2.3.2: The dynamic type of a value may be more specific than the static type of the expression that computed it.) 3.12.3: cast is supported if the input type is a non-primitive atomic type that is derived by restriction from the target type. In this case, the input value is mapped into the value space of the target type, unchanged except for its type. For example, if shoesize is derived by restriction from xs:integer, a value of type shoesize can be cast into the schema type xs:integer. My reading is that 3.12.3 requires that the result is an instance of xs:integer, but 3.1.5 allows that it might also be an instance of xs:byte. The phrase "unchanged except for its type" does not disallow returning the type unchanged. The reason Saxon behaves this way is that the compiler often generates unnecessary casts and then optimizes them away in a subsequent phase of analysis. If I weren't allowed to optimize the cast away, I would have to distinguish an cast created by the compiler from one that was written by the user. Michael Kay http://www.saxonica.com/
Received on Friday, 24 February 2006 10:26:55 UTC