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

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. 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>

Michael Kay
Saxonica


> On 18 May 2020, at 17:52, Graydon graydon(_at_)marost(_dot_)ca 
> <xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
>
> https://archive.xmlprague.cz/2020/files/xmlprague-2020-proceedings.pdf#page=121
>
> says in 5.1:
>
> > A template rule with a select attribute must not contain any xsl:param
> > or xsl:context-item declarations.
> I can easily imagine wanting xsl:param, particularly a tunnel parameter.
> For example, if the template functions to construct a target URI it
> would be helpful to be able to pass in the base URI as a parameter.
>
>
> -- 
> Graydon Saunders  | graydonish(_at_)gmail(_dot_)com
> Þæs oferéode, ðisses swá mæ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/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--