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 29732 - [xslt30] Streamable stylesheet functions: shallow-descent example
Summary: [xslt30] Streamable stylesheet functions: shallow-descent example
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: 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: 2016-07-15 10:13 UTC by Michael Kay
Modified: 2016-10-28 16:51 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2016-07-15 10:13:01 UTC
Our example of a shallow-descent streamable function does not satisfy the rules in the spec. The rules say:

If the declared type of the streaming parameter permits more than one node, then a variable reference referring to the streaming parameter is roaming and free-ranging. 

But the declared type in this case is element(*).

(It seems somewhat perverse that this should be expressed as a rule on the variable reference, rather than a rule on the function signature - as if it's OK to specify element()* in the function signature so long as the argument is never used. But if that's the case then the function body can't possibly be striding. It would seem more sensible to have a rule against the function signature. We might also note that if the first argument does not permit nodes, then the function body will never be striding.)

I don't recall the reasoning that led us to allow multiple nodes in the call of an absorbing function, but not to allow the same in a call of a shallow-descent function
Comment 1 Michael Kay 2016-09-22 10:13:25 UTC
PROPOSAL:

(A) In 19.8.5 change the paragraph

The choice of category places constraints on the function body, and on calls to the function. These constraints are defined below, separately for each category. A function is guaranteed-streamable only if the constraints are satisfied.

to say

The choice of category places constraints on the function declaration, and also on calls to the function. These constraints are defined below, separately for each category. A function is guaranteed-streamable only if the constraints on the function declaration are satisfied, and a static function call is guaranteed-streamable only if the function is guaranteed-streamable and the function call satisfies the constraints for the chosen category.

Dynamic function calls are guaranteed-streamable only in trivial cases, for example where the function signature indicates that an argument is required to be a text node or an attribute node. For details see streamability-of-dynamic-function-calls.

(B) In the individual function categories (sections 19.8.5.x), add a subheading "Rules for the function signature" before "Rules for the function body". Except where otherwise specified, populate this with the text "There are no constraints".

For category inspection, where we currently say:

Rules for references to the streaming parameter: If the declared type of the streaming parameter permits more than one node, then a variable reference referring to the streaming parameter is roaming and free-ranging. Otherwise such a variable reference is striding and motionless.

change this to:

Rules for the function signature: If the declared type of the streaming parameter permits more than one node, the function is not guaranteed-streamable.

Rules for references to the streaming parameter: Such a variable reference is striding and motionless.

Ditto (mutatis mutandis) for the categories filter, shallow-descent, deep-descent, and ascent.

(C) Change the affected examples for the categories filter, shallow-descent, deep-descent, and ascent.

In all cases this only involves changing the "as" attribute of the function signature and some minor changes to the explanation of what the example function does.
Comment 2 Sharon Adler 2016-10-12 14:17:52 UTC
Bug to be closed.
Comment 3 Michael Kay 2016-10-28 16:51:04 UTC
The changes have been belatedly applied.