Re: How do I pass the mode as a string?

Hi,

For the situation described, I would probably find a way to use tunnel
parameters or perhaps two passes.

One approach to consider would be to qualify processing not with modes
but by means of stylesheet parameters, referenced by template matches
and set at runtime --

<xsl:param name="one-condition" as="xs:boolean" select="false()"/>

<xsl:template match="elem[$one-condition]">...

<xsl:template match="elem[$another-condition]">...

This is similar to using a function, as was I think suggested --

<xsl:template match="elem[my:doc-id(.) ! my:doc-id-in-range(.)]">...

I am also hoping that Liam suggests generating the templates
dynamically, then using the transform() function to apply them. This
works too (although again, perhaps not for this actual problem).

Cheers, Wendell

On Tue, Mar 3, 2020 at 1:37 PM David Carlisle d.p.carlisle@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 3 Mar 2020 at 17:22, Liam R. E. Quin liam@xxxxxxxxxxxxxxxx
> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, 2020-03-03 at 11:54 +0000, David Carlisle
> > d.p.carlisle@xxxxxxxxx wrote:
> > > essentially that's not possible: the mode needs to be a literal at
> > > compile time not any kind of variable
> >
> > As Nartin i think will point out later in this thread :) in XSLT 3 you
> > can use shadow attributes and _mode="$staticmode" where $staticmode is
> > a stylesheet parameter declared with static="yes" - for any XSLT
> > attribute. I've also used this for xsl:output's doctype attribute,
> > which is neither an AVT nor an expression.
> >
> > Liam
> >
>
> yes so I suppose "value determined at compile time" rather than
> "literal" for xslt 3, but either way it's no use if the OP wants two
> values in the same run:-)
>
> David
> 



-- 
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...