I agree with Michael Rys's reading. I don't think that constructor functions should be considered as standard function calls. Section 3.12.5 Constructor Functions seems to be pretty clear about it: [Definition: The constructor function for a given type is used to convert instances of other atomic types into the given type. The semantics of the constructor function T($arg) are defined to be equivalent to the expression ($arg cast as T?).] - Jerome www-ql-request@w3.org wrote on 02/24/2006 05:23:54 AM: > > > 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 16:22:40 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 22 July 2006 00:10:21 GMT