Re: saxon:evaluate() (was: sorting and parameters)

Subject: Re: saxon:evaluate() (was: sorting and parameters)
From: Steve Tinney <stinney@xxxxxxxxxxxxx>
Date: Tue, 18 Jan 2000 21:00:41 -0500
Kay Michael wrote:
> I think it will do this, if I've understood what you're looking for. I
> assume $variable holds an element name, e.g. "title", so
>    <xsl:variable name="variable" select="'title'"/>
>    <xsl:variable name="path" select="concat('$nodes/some/', $variable)"/>
>    <xsl:variable name="newset" select="saxon:evaluate($path)"/>

I'm sorry.  You wrote: concat('$nodes'...; but I read: concat($nodes...

> we can get round the restrictions by introducing reflexion, i.e. allowing
> expressions in the language to be generated and evaluated at run-time. We
> can't have a variable whose value is a Step, but we can have a variable
> whose value is a character string that can be parsed as a Step.
> I'm beginning to wonder whether this new function will generate more
> perplexity than it is worth. If people can't cope with attribute value
> templates, they're going to sink up to their necks in this one. Is the world
> ready for reflexive languages? 

Speaking as a naive user, I would just like to be able to specify a part
of a path (a step) in a variable.  The concat() workaround is fine with
me; heck, I've suffered \noexpand, \expandafter, \futurelet and such
stuff for years.

Still, I can't help thinking that a language that has been developed
with ease of use in mind would be easier still to use if some key
implementation issues were not allowed to erupt at the user level.  I
think that variable interpolation, when, where and how, ranks with the
great node-set vs. RTF question.


How many times do I have to tell you?  Read 
what is there, not what you think is there --- My mum, circa 1970.

 XSL-List info and archive:

Current Thread