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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--