Re: Filtering, xslt 2.0

Hi,

To Dave C's remark, indeed, I have been noticing a general pattern in
parameterization - an external parameter coupled to an internal variable
that represents that parameter meaningfully.

<xsl:param name="verbose" as="xs:string">no</xsl:param>
<xsl:variable name="running-verbose" as="xs:string*" select="$verbose =
('yes','true','Y','y')" />

This way you always pass in a string, and the internals work out the
details, and defaulting can be a little more graceful.

Cheers, Wendell



On Wed, Nov 2, 2022 at 8:34 AM David Carlisle d.p.carlisle@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
>
> On Wed, 2 Nov 2022 at 12:13, Dave Pawson dave.pawson@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> For the archive: My solution
>>
>>   <xsl:param name="types" as="xs:string*"/>
>>
>>
> You should use xs:string not xs:string* as if you passed in a sequence
> your later tokenize would fail.
>
> I'd do
>
> <xsl:param name="types" as="xs:string*"/>
> <xsl:variable name="typesseq" as="xs:string*" select=" tokenize($types, ',
> *') />
>
> Then use the sequence explicitly rather than relying on the optimiser to
> avoid tokenizing on every use.
>
>
>   <xsl:when test="type = $typesseq ">
>
> David
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/174322> (by
> email <>)
>


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