- 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