[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Equal rights for xsl:next-match & co


Subject: Re: [xsl] Equal rights for xsl:next-match & co
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxx>
Date: Mon, 27 May 2013 18:29:34 -0400

Evan,

It's something of a hack, but isn't this problem reasonably easily
gotten around (at least in many cases) by naming your
template-to-be-matched-next, and calling it by name? (At least if I
understand you correctly.)

Or (in some other cases) by overloading templates with more than one mode:

<xsl:template match="x[$y]">
    <xsl:variable name="this" select="."/>
    <xsl:for-each select="$sequence">
      ..
      <xsl:apply-templates select="$this" mode="next"/>
    </xsl:for-each>
</xsl:template>

<xsl:template match="x" mode="#default next">
  ...
</xsl:template>

xsl:next-match works as well as it does, in part, because one can
determine relatively easily how things like context size and position,
parameters in scope and so forth, should work. I'm afraid that if it
were extended to work once the original context were no longer the
context, other things would commonly go awry.

(Should next-match also work within a template called by name?)

Cheers, Wendell


On Tue, May 21, 2013 at 2:32 PM, Evan Lenz <evan@xxxxxxxxxxxx> wrote:
> To me, it doesn't make sense to say "next match on the current node." (What
does that even mean?) No, it's simply the next match; the only match we could
be talking about is the match that occurred: the node that matched and
triggered the rule represented by the xsl:template ancestor. That it happens
to have always been coincident with the current node is a consequence of the
arbitrary restriction imposed by XSLT 2.0. That's the way I look at it. :-)
>
> Evan
>
> On May 21, 2013, at 9:25 AM, David Carlisle <davidc@xxxxxxxxx> wrote:
>
>> On 21/05/2013 17:12, Evan Lenz wrote:
>>> <xsl:for-each select="1 to 10">
>>>   <xsl:next-match/>
>>> </xsl:for-each>
>>
>> well yes matching on the original node would be reasonably intuitive if the
for-each is iterating over atomic items, but I think it would be pretty odd to
do that if it was iterating over nodes, and  the sequence might be a mix of
both and you can't statically tell which is which so
>> not allowing it seems a safe first step:-)
>>
>> David
>>
>>
>> ________________________________________________________________________
>> The Numerical Algorithms Group Ltd is a company registered in England
>> and Wales with company number 1249803. The registered office is:
>> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>>
>> This e-mail has been scanned for all viruses by Star. The service is
>> powered by MessageLabs.
________________________________________________________________________
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^


Current Thread
Keywords