This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XPath 3.0 claims in 2.5.2 that casting to a namespace-sensitive type raises XPTY0117 if the prefix is not in scope. This is incorrect. F+O, which has the definitive specification for casting, says this is a dynamic error FONS0004. This must be a dynamic error rather than a type error because it depends on knowledge of the actual supplied value. XPTY0117 is in fact a different error: it is raised when an untypedAtomic value is supplied to a function that expects a QName (regardless whether the prefix is in scope or not). The error is correctly described in 3.1.5.2 (function conversion rules) but is wrongly described in the error codes appendix.
I agree.
I'm reopening this because the text of XPTY0117 says: "In a cast expression, if an item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised." yet the error is only raised in function conversion (3.1.5.2 Function Conversion Rules), and NOT casting. Also in that section we read "Each item in the atomic sequence that is of type xs:untypedAtomic is cast to the expected generalized atomic type. For built-in functions where the expected type is specified as numeric, arguments of type xs:untypedAtomic are cast to xs:double. If the item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised." The text "If the item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised." should probably come first here to indicate that a cast is NOT attempted. Although this is a bug in 3.0, I'll hope it can be fixed in 3.1 and have marked it as a bug against 3.1.
Note that in XQ10 casting from xs:untypedAtomic to xs:QName was not permitted. In XQ30, it was permitted. Following the text as written, and using the example below declare function local:example($arg as xs:QName) { ... }; local:example( xs:untypedAtomic("missingPrefix:localName") ) 1. Each item in the atomic sequence that is of type xs:untypedAtomic is cast to the expected generalized atomic type. Cast from xs:untypedAtomic("localName") to QName - fails with FONS0004 because the prefix is not bound in the static context. However, this should have been prevented (possibly statically) by an XPTY0017. Therefore I propose reordering the text to be: * For built-in functions where the expected type is specified as numeric, arguments of type xs:untypedAtomic are cast to xs:double. * If the item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised. * Otherwise, each item in the atomic sequence that is of type xs:untypedAtomic is cast to the expected generalized atomic type
I will rewrite the error code. In http://www.w3.org/TR/2014/WD-xquery-31-20140424/#id-function-conversion-rules, we will change bullet point to: 2. If the item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised. If no type error is raised, each item in the atomic sequence that is of type xs:untypedAtomic is cast to the expected generalized atomic type. For built-in functions where the expected type is specified as numeric, arguments of type xs:untypedAtomic are cast to xs:double.
I assume that these three points follow atomization in your proposal: * For built-in functions where the expected type is specified as numeric, arguments of type xs:untypedAtomic are cast to xs:double. * If the item is of type xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised. * Otherwise, each item in the atomic sequence that is of type xs:untypedAtomic is cast to the expected generalized atomic type
Proposed text for this error: During function argument conversion, if the actual type is xs:untypedAtomic and the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised.
For each xs:untypedAtomic item in the sequence: * If the expected type is namespace-sensitive, a type error [err:XPTY0117] is raised. * If the expected type is numeric, the item is cast to xs:double. * Otherwise, the item is cast to the expected generalized atomic type.
The Working Group resolved this by accepting comment #6 and comment #7.
For the record: as the reopener of the issue, Tim Mills is asked to consider the resolution of the issue, and to signal his assent to this resolution by closing the bug (or, if necessary, his dissent, by reopening it). If the bug has not been closed by the time the WG prepares to progress the specifications, silence will be interpreted as assent Also for the record: it took the WG some little time to realize that the three sentences in the status-quo text of numbered item 2 in the first bullet item in section 3.1.5.2 are not to be taken as sequential instructions, but the second and third sentences are to be read as expanding on the instruction given in the first sentence and supplying details (and/or special cases / exceptions). We hope that the wording finally adopted helps make the logical relation clear.
Thanks.