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 5464 - [XSLT 2++] Enhancement: generalizing patterns
Summary: [XSLT 2++] Enhancement: generalizing 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 XP
: 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:
: 5840 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-02-08 14:37 UTC by Michael Kay
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2008-02-08 14:37:11 UTC
Path expressions became a lot more flexible in XPath 2.0, but little of this flexibility was passed on to XSLT patterns. Some patterns which we don't currently allow, but which could be very useful:

(chapter//footnote)[1]

book/(chapter|appendix)

node() except element()

We should review the subset of XPath syntax that is allowed in XSLT patterns and only prohibit constructs where there is a good reason.
Comment 1 Michael Kay 2008-09-03 08:40:35 UTC
Some specific suggestions for enhancements:

(a) allow a variable reference at the start of the pattern, for example $lookup//data. Can be written currently as data[ancestor::node() intersect $lookup], but that's pretty cumbersome. Useful to specify that a template rule is applicable only to one specific document.

(b) this also allows match="$nodeset" where $nodeset is a global variable. The pattern then matches all nodes in this nodeset. Useful in cases where it is easier or more efficient to select some set of nodes (often those to be treated as exceptions) in a global variable. I've seen this in WordXML documents: "ignore the first w:d element after any w:img element that has a w:text descendant", etc.

(c) allow the first step to be a call on doc() or document(). Achieves the same thing but without the need for a global variable.

A more radical idea is to allow the match pattern of an xsl:template to reference the template parameters. So if the xsl:apply-templates specifies <xsl:with-param name="color" select="'red'"/> then a template with match="*[$color='blue']" will not be selected. 
Comment 2 Michael Kay 2008-09-26 13:22:07 UTC
*** Bug 5840 has been marked as a duplicate of this bug. ***
Comment 3 Michael Kay 2009-03-24 08:24:19 UTC
Another one that comes up (see Christian Roth on xsl-list today) is to match the first descendant of something, e.g. chapter/descendant::para[1] or (chapter//para)[1]. Neither syntax is currently allowed.
Comment 4 Michael Kay 2009-05-07 09:46:50 UTC
A proposal for patterns to match atomic values is at

http://lists.w3.org/Archives/Member/w3c-xsl-wg/2009Apr/0070.html

(member-only link)

It does not address all the requirements raised here.
Comment 5 Michael Kay 2010-04-15 16:47:54 UTC
This is done in the current (internal) working draft