22127 2013-05-21 21:41:46 +0000 Allow xsl:next-match inside xsl:for-each 2014-05-15 14:00:45 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Working drafts PC Windows NT CLOSED WONTFIX P2 normal --- 1 evan mike public-qt-comments oldest_to_newest 88025 0 evan 2013-05-21 21:41:46 +0000 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 88032 1 mike 2013-05-21 22:30:41 +0000 I'd like to see a compelling use case. My instincts are against adding more "current this" and "current that" values; even if scoped statically to a template rule, they add semantic complexity. For example, this facility would complicate the streamability rules. If we did introduce a "current matched node" I think we would need an interrogative function to return it. (In practice, I suspect this new function would then be used a lot more than the proposed xsl:next-match facility...) 91461 2 mike 2013-07-31 15:51:30 +0000 The WG reviewed this and decided that in the absence of a compelling use case the WG was inclined to make no change in this area. Unless we have further input before 1 September we will close this with no action.