Re: [xsl] XSLT 4: xsl:template/@select

["Alan Painter alan.painter@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Ah, OK, thanks for setting me straight.  I was just about to change some
templates to try this.

On Tue, May 19, 2020 at 10:26 AM Michael Kay mike@xxxxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> I hadn't realized that it was possible to include template parameters as
> part of the template match rule.
>
>
> It isn't! It's a feature that I would sometimes like to have, and that
> other people also seem in favour of. But at the moment, local parameters
> are not in scope for the match pattern.
>
> Michael Kay
> Saxonica
>
>
> That would definitely simplify some things that I was doing recently where
> I was matching more general cases and then, upon checking against the
> template parameter, I would call "xsl:next-match" to choose the
> next-in-line template.
>
> Excellent, I'll go back and give that a shot.
>
> Thanks for the excellent tip.
>
> On Tue, May 19, 2020 at 3:21 AM BR Chrisman brchrisman@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> ohhh xsl:mode enclosing templates.. I use that a lot in generated
>> stylesheets... it just makes so much sense.... looking forward to
>> that!
>>
>> On Mon, May 18, 2020 at 11:52 AM Graydon graydon@xxxxxxxxx
>> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> >
>> > On Mon, May 18, 2020 at 05:04:12PM -0000, Michael Kay mike@xxxxxxxxxxxx
>>  scripsit:
>> > > I didn't want to create messy scoping rules for variables, e.g.
>> > >
>> > > <xsl:template match="type(xs:integer)" mode="increment" select=".+1"/>
>> > >
>> > > is fine, but
>> > >
>> > > <xsl:template match="type(xs:integer)" mode="increment"
>> select=".+$delta">
>> > >   <xsl:param name="delta" as="xs:integer"/>
>> > > </xsl:template>
>> > >
>> > > feels a bit weird.
>> >
>> > I can't speak to feel at all, and I have no knowledge of how difficult
>> > it makes the scoping rules to implement, but that second example is to
>> > me obviously ever so much more useful.  It implies one could do things
>> > like perform a simple numbering pass and then have one template that
>> > went through and attached all the appropriate names -- part, chapter,
>> > section, etc. -- on a second pass by matching the numbers, with the text
>> > provided by parameter.
>> >
>> > > We had similar issues with xsl:iterate - the reason xsl:on-completion
>> comes first is to avoid creating custom rules for variable scoping.
>> > >
>> > > Using params in match patterns gets even more interesting - useful,
>> but hairy:
>> > >
>> > > <xsl:template match="para[@class=$class]">
>> > >   <xsl:param name="class"/>
>> > >   ...
>> > > </xsl:template>
>> >
>> > I cannot tell you how many times I have wanted to be able to do that.
>> >
>> > There's -- I think there is -- an appropriate caution with template
>> > predicates so that you have templates to match every possible, rather
>> > than every expected, case.  Being able to stuff all of that logic into
>> > whatever singular thing assigns the value to $class, rather than
>> > distributing it over a bunch of templates' individual predicates, would
>> > be extremely helpful.
>> >
>> > (And yes it starts to be a special case of XPath macros, but I would
>> > like those, too.)
>> >
>> > --
>> > Graydon Saunders  | graydonish@xxxxxxxxx
>> > CC&s oferC)ode, C0isses swC! mC&g.
>> > -- Deor  ("That passed, so may this.")
>> >
>>
>> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/293509> (by
> email)
>
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/552232> (by
> email <>)