22937 2013-08-13 11:49:42 +0000 [xslt 3.0] Rules for streamable patterns 2014-05-15 14:00:38 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Working drafts PC All CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 91977 0 mike 2013-08-13 11:49:42 +0000 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. 91978 1 mike 2013-08-13 11:53:20 +0000 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]" 92087 2 mike 2013-08-15 11:02:14 +0000 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,':')] 93652 3 mike 2013-09-23 16:16:52 +0000 The changes described here have been applied to the spec.