This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
treat-as-5, treat-as-24 and treat-as-25 give me errors because they treat an xs:decimal as an xs:integer: let $var := xs:decimal(100) return fn:abs($var treat as xs:integer) I think this is an incorrect query - $var has the dynamic type of xs:decimal, and treating it as an xs:integer is simply wrong.
Martin: Can you be more specific on your comment. What do you mean it is simply wrong? Thanks, Carmelo
Quoting from the spec (http://www.w3.org/TR/xquery/#id-treat): During expression evaluation: If expr1 matches type1, using the rules for SequenceType matching, the treat expression returns the value of expr1; otherwise, it raises a dynamic error [err:XPDY0050]. If the value of expr1 is returned, its identity is preserved. The treat expression ensures that the value of its expression operand conforms to the expected type at run-time. So at runtime, the dynamic type of $var is xs:decimal. The way I read the specs (correct me if I'm wrong!) a type of xs:decimal does not match a required type of xs:integer, as xs:integer inherits from xs:decimal, so this is somewhat of a "down cast". Casting would of course work, but that's not the idea of treat as, as far as I understand it.
Martin: This is true of for "treat-as-5.xq", but not for 24 and 25. Can you double check? Thanks, Carmelo
Martin: Changed the query a bit to get around the type issue, by using a combination of cast/treat (as in some other cases). Submitted changed tests and results. Please close the bug if in agreement. Thanks, Carmelo
I checked for 24 and 25, it's a little bit hidden in the spec but quoting http://www.w3.org/TR/xpath-functions/#func-numeric-divide : > As a special case, if the types of both $arg1 and $arg2 are xs:integer, > then the return type is xs:decimal. So the dynamic type of $var in (from 24, 25 is identical except for - 10) let $var := (100+200) div 10 return ($var treat as xs:integer) + 10 is xs:decimal, causing the latter "treat as" to fail, so this needs a resolution too. I'll check your solution as soon as it's released.
Martin: Applied the same fix to all three tests. Looks as though that message got lost yesterday within bugzilla. Thanks, Carmelo