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

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

> 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
<mailto:brchrisman@xxxxxxxxx> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx
<mailto: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
<mailto:graydon@xxxxxxxxx>
> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx
<mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
> >
> > On Mon, May 18, 2020 at 05:04:12PM -0000, Michael Kay mike@xxxxxxxxxxxx
<mailto: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 <mailto: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 <>)