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 22937 - [xslt 3.0] Rules for streamable patterns
Summary: [xslt 3.0] Rules for streamable patterns
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working drafts
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: 2013-08-13 11:49 UTC by Michael Kay
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2013-08-13 11:49:42 UTC
The rules for motionless patterns in 19.3.10 say:

(a) The expression in the predicate must be motionless.

(b) The predicate must not contain a call on either of the functions position or last.

Now, the second condition is not complete, because we must also eliminate indirect calls via named function references or function-lookup().

Also, the second condition is stricter than it needs to be. For example, it disallows a pattern such as

match="p[. = $special[last()]]"

And perhaps the second condition is redundant?

Certainly the ban on last() appears redundant, because if the expression contains a call on last() other than one masked as in this example, then it will not be a motionless expression (last() is free-ranging). But calls to position() are allowed in a motionless expression. For clarity, it seems best to ignore the partial redundancy and leave the ban on position() in place.

So I propose to change rule (b) to:

(b) The predicate must not contain any of the following, unless it occurs within a nested predicate:

(i) A function call to position, last, or function-lookup
(ii) A named function reference that references position, last, or function-lookup

I would propose to make the meaning of "nested predicate" clear by means of examples; and then add a Note to say that the ban on last() is redundant.
Comment 1 Michael Kay 2013-08-13 11:53:20 UTC
I also propose to refine the rules for expressions that return booleans as follows:

(a) allow a return type of S where S satisfies subtype(S, xs:boolean?) - which allows subtypes of xs:boolean as well as xs:boolean itself

(b) allow "treat as xs:boolean" - again allowing subtypes

I wonder whether we should also allow expressions that are statically known to return nodes? For example it seems unreasonable to disallow

match="p[@status]"
Comment 2 Michael Kay 2013-08-15 11:02:14 UTC
I have (subject to WG approval) extended the rules to allow in predicates all expressions where relatively simple type analysis shows them to be non-numeric. This therefore allows patterns such as 

p[@class]
p[@class|@style]
p[substring-after(@class,':')]
Comment 3 Michael Kay 2013-09-23 16:16:52 UTC
The changes described here have been applied to the spec.