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 30322 - [XSLT30] the streamability rules on fn:error contain references to 5- and 6-argument functions that do not exist, and assumes a context item
Summary: [XSLT30] the streamability rules on fn:error contain references to 5- and 6-a...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-01 22:34 UTC by Abel Braaksma
Modified: 2018-12-01 22:34 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2018-12-01 22:34:22 UTC 
The text in 19.8.9 on Classifying Calls to Built-In Functions contains entries for each built-in function, but the entry on fn:error seems skewed:

* fn:error() – Equivalent to fn:error(x, x, x, x, x, .)
* fn:error(x) – Equivalent to fn:error(x, x, x, x, .)
* fn:error(x, x) – Equivalent to fn:error(x, x, .)
* fn:error(A, A, N)

Instead, this was probably intended to be:

* fn:error() – Equivalent to fn:error(.)
* fn:error(x) – Equivalent to fn:error(x, .)
* fn:error(x, x) – Equivalent to fn:error(x, x, .)
* fn:error(A, A, N)

But that doesn't seem to match with the fn:error definition, which doesn't depend on the context item. Instead, I think, something along those lines could work:

* fn:error() – Equivalent to fn:error(fn:QName('http://www.w3.org/2005/xqt-errors', 'err:FOER0000'))
* fn:error(x) – Equivalent to fn:error(x, "error"))  -- any static text works
* fn:error(x, x) – Equivalent to fn:error(x, x, ())
* fn:error(A, A, N)

Since the third argument is implementation-dependent, it *could* return the current node, if any, if an implementation chooses so, but that is by no means a requirement.

The third argument is classified as N. I'm not sure that N is necessary, I think that A (absorption) would work here too, though that requires a processor to create a copy whenever the error is caught. But 'N' is not wrong per se, so considering REC status I assume we should leave it at that.

Also, the 'x' is not explained anywhere (though from context and description, I doubt its meaning is unclear to readers).