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

Subject: Re: [xsl] XSLT 4: xsl:template/@select
From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 May 2020 18:52:17 -0000
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
^fs oferiode, pisses swa mfg.
-- Deor  ("That passed, so may this.")

Current Thread