[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.