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 12455 - [XSLT 3.0] Predicates in new-style patterns
Summary: [XSLT 3.0] Predicates in new-style patterns
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working drafts
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: 2011-04-08 13:30 UTC by Michael Kay
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2011-04-08 13:30:06 UTC
In 5.5.3 rules 5 and 6 we talk of an item "satisfying a predicate". We don't say exactly what we mean by this. Examples are

~xs:integer[. gt 0]

(foo|bar)[baz]

There are two ways we could define it:

(a) we simply take the effective boolean value of the predicate

(b) we apply the usual rules for filter expressions, with the special interpretation of [position() = N] if the value is numeric.

Note that numeric predicates here have no practical utility, because the focus is always a singleton (position() is always 1). So we have a choice between a rule that is simple (a), or a rule that is consistent with elsewhere (b).

We might also want to reconsider the use of a singleton focus for a pattern like (foo|bar). It means that match="(foo|bar)[last()]" does not do what the user probably expects.
Comment 1 Michael Kay 2012-02-19 21:46:48 UTC
This was discussed during the Feb 2012 F2F. It was felt we should try to restore the semantic connection between patterns and XPath expressions in order to avoid surprises in this area (or at any rate, to make it possible to defend the surprises).

I would suggest doing this as follows.

(a) the construct ~typename is replaced by (.[. instance of typename]). This substitution is incorporated into the definition of "equivalent expression"

(b) the ability to use union/intersect/except with non-node patterns is dropped

(c) the current rule

An item N matches a PathPattern if N is a node and the result of evaluating the expression root(.)//(EE) with a singleton focus based on N is a sequence that includes the node N, where EE is the equivalent expression to the PathPattern,

is replaced by

An item N matches a PathPattern if either of the following applies:

(1) N is a node and the result of evaluating the expression root(.)//(EE) with a singleton focus based on N is a sequence that includes the node N, where EE is the equivalent expression to the PathPattern,

(2) N is not a node and the result of evaluating the expression exists(EE) with a singleton focus based on N is true.
Comment 2 Michael Kay 2012-03-15 13:54:31 UTC
This change was accepted by th WG on 8 Mar 2011, and has been applied (with some editorial license).