This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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]"
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,':')]
The changes described here have been applied to the spec.