- From: <bugzilla@jessica.w3.org>
- Date: Tue, 21 May 2013 21:41:46 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22127
Bug ID: 22127
Summary: Allow <xsl:next-match/> inside <xsl:for-each>
Classification: Unclassified
Product: XPath / XQuery / XSLT
Version: Working drafts
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: XSLT 3.0
Assignee: mike@saxonica.com
Reporter: evan@evanlenz.net
QA Contact: public-qt-comments@w3.org
I've tried this on a couple of occasions but was disappointed to see that it
didn't work. I understand that the semantics need some defining, but from the
user's perspective there's only one behavior that makes sense: run the
next-match based on the node that was matched (which may not be the current
node if inside xsl:for-each). Call it the "currently matched node" if
necessary. I don't believe it would make sense to say "next-match" on any other
node (such as the current node), because there would no longer be a comparison
by which another match could be said to be "next"; my point here is that
there's no ambiguity problem.
It can be useful for "fanning out" the matched node, where the first match does
the fanning and the next match does the processing, all in the same mode. That
it's a next match (in the same mode) rather than using a new mode is important
because the first-matching template rule could be associated with more than one
mode (to support multiple fanning scenarios, for example). Also, you may want
to pass a different parameter for each <xsl:for-each> iteration.
My contention is that xsl:next-match (and xsl:apply-imports) should not be
defined in terms of the current node but rather the currently matched node,
thereby removing the restriction; and that <xsl:for-each> shouldn't nullify the
current template rule.
Evan
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 21 May 2013 21:41:51 UTC