- From: <bugzilla@jessica.w3.org>
- Date: Tue, 19 Mar 2013 10:51:24 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21332 Bug ID: 21332 Summary: [XP30] Literal out of range: static or dynamic error? Classification: Unclassified Product: XPath / XQuery / XSLT Version: Candidate Recommendation Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XPath 3.0 Assignee: jonathan.robie@gmail.com Reporter: mike@saxonica.com QA Contact: public-qt-comments@w3.org Test case fn-function-arity-017 does this fn:function-arity( fn:concat#340282366920938463463374607431768211456 ) and permits the error FOAR0002. The thinking here is presumably that the syntax describes the arity as an IntegerLiteral; the semantics of an IntegerLiteral are that it is converted to an integer using the string-to-integer conversion rules; and these rules say that if the integer is outside the implementation-defined range, a dynamic error FOAR0002 occurs. There are several problems here. (a) The range allowed for a function arity may be smaller than the range allowed for xs:integer. For example, it may be limited to 31 bits (!). (b) FOAR0002 is a dynamic error. If this is going to be an error, it surely makes sense for it to be a static error. And the same goes of course for an IntegerLiteral (or any other literal) appearing directly in the query in any other context. The distinction between static and dynamic errors needs to be made much more carefully in the context of try/catch. I'm encountering such problems as a result of converting QT3 tests to XSLT3 tests, where static and dynamic errors are handled differently by the test driver. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 19 March 2013 10:51:25 UTC