This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20310 - [XQ 3.0] Limits
Summary: [XQ 3.0] Limits
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-08 17:37 UTC by Michael Kay
Modified: 2012-12-20 23:45 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2012-12-08 17:37:06 UTC
One of the tests in QT3 (cbcl-subsequence-010) does this:

count(subsequence(1 to 3000000000, -2147483648, 2147483647))

Now, I think we would probably agree that we don't require implementations to support sequences as long as 3,000,000,000 items, and that it's acceptable for implementations to fail to process this query.

XDM says nothing about limits. I guess we traditionally think of limits (for some reason I don't fully understand) as a conformance issue, and conformance issues are (again by tradition) tackled only the XSLT and XQuery specifications. Fair enough.

XSLT and XQuery both have sections on limits. For some reason the XSLT specification includes the statement "For sequences, the maximum number of items in a sequence [is implementation-defined" whereas the XQuery limits section says nothing on the subject.

Neither specification says anything about what should happen if a limit is exceeded. There's no error code defined. That makes it difficult to make any assertion about the outcome of the test cited above. Do we want to impose a requirement that it either delivers a well-defined answer (the test as written expects the answer 0) or an error? Or do we want to allow it to return, say, 42?

I think my preference would be to say that "wrong answers" are not an acceptable outcome when limits are exceeded. This is what we say for integer arithmetic, for example (or at any rate, we require implementations at least to provide a mechanism which allows users to select this behaviour). I would like to say that exceeding the implementation-defined limit on the length of a sequence results in an error, and I would like to allocate an error code so that the above test can be given two alternative outcomes: the value zero, or a defined error code.
Comment 1 Andrew Eisenberg 2012-12-17 16:32:24 UTC
XQuery 3.0, in section 2.3.1, Kinds of Errors, says:

"In addition to the errors defined in this specification, an implementation may raise a dynamic error for a reason beyond the scope of this specification. For example, limitations may exist on the maximum numbers or sizes of various objects. Any such limitations, and the consequences of exceeding them, are implementation-dependent."
Comment 2 Michael Kay 2012-12-17 16:56:51 UTC
(In reply to comment #1)
> XQuery 3.0, in section 2.3.1, Kinds of Errors, says:
> 
> "In addition to the errors defined in this specification, an implementation
> may raise a dynamic error for a reason beyond the scope of this
> specification....

I think I would ask for two things.

(1) a statement that the implementation-dependent behaviour when a limit is exceeded must be an error of some kind; it is not acceptable, for example, for count(1 to 1e100) to return 42.

(2) an error code which is available for use to indicate that a limit has been exceeded. We should not require use of this error code (implementations might, for example fail with conditions such as "heap full") but we should encourage its use where possible, and we should use this code as a potential result of test cases that stray beyond the minimal limits.
Comment 3 Jonathan Robie 2012-12-20 23:45:30 UTC
I adopted Andrew's solution:

<quote>
In addition to the errors defined in this specification, an implementation may raise a dynamic error for a reason beyond the scope of this specification. For example, limitations may exist on the maximum numbers or sizes of various objects. An error must be raised if such a limittation is exceeded.
</quote>