it can lead to XPath injection vulnerability ;)

look like in your case you can use only element name instead full
XPath from root

if suggest that xpath contain only element name then

<xsl:apply-templates match="$xpath"/> should look like

<xsl:apply-templates match="//*[local-name() = $xpath]"/>

(: but for your XSLT processor /rolodex/entry/* instead //* can be
much faster probably :)

also i should note that using XSLT for filtering is little expensive -
for best results you can try  to use XQuery & XML Database with
indexing support (eXist for example).

with best wishes,
Slav

On Tue, Jun 16, 2009 at 8:21 AM, ac<ac@xxxxxxxxxxxxx> wrote:
> Hi,
>
> First, again, it seems to me that the "eval" extension should be part of
the
> standard and that the other options presented here are just trying to
create
> an "eval" function that would be "in the standard" without being standard,
> at quite a high development,  maintenance, and operational cost.
>
> My suggestion is: use the "eval" extension, in an implementation that
> supports it, until it is included in the standard.
>
> Let's make sure that "eval" (or similar) is included in the next XSLT
> revision.
>
> Cheers,
> ac
>
>
>
>> On Mon, Jun 15, 2009 at 08:04:48PM -0700, John Christopher wrote:
>>
>>>
>>> My goal: I want an XSLT stylesheet that displays the contents
>>> of any element or attribute whose name I pass to the stylesheet
>>> as an XPath via a param.
>>>
>>
>> [...]
>>
>> There are three main approaches I can think of here.
>>
>> (1) write an XSLT stylesheet that generates a new stylesheet in
>> which those XPath fragments (or template match patterns) are
>> in fact hard-coded...
>>
>> (2) use the eval extension in an implementation that provides it
>>
>> (3) interpret the XPath expression in XSLT.
>>
>> E.g.
>> <xsl:template match="*">
>>  <xsl:param name="name" />
>>
>>  <xsl:if test="localname() = $name">
>>     <xsl:message>got one!</xsl:message>
>>  </xsl:if>
>>  <xsl:apply-templates />
>> </xsl:template>
>>
>> Well, this doesn't handle a/b, but you could use substring-after
>> to handle that, or, in XSLT 2, you could split the string on "/"
>> and then look for predicates, and you could do fancy things with count()
>> to sort into document rder & weed out duplicates.
>>
>> But I'd favour approach (1) probably.
>>
>> Liam