This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Template rules vs. XQuery (was RE:"*NEVER* use for-each")
- To: "Evan Lenz" <elenz at xyzfind dot com>
- Subject: Re: [xsl] Template rules vs. XQuery (was RE:"*NEVER* use for-each")
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Wed, 28 Feb 2001 09:04:56 +0000
- CC: xsl-list at lists dot mulberrytech dot com
- Organization: Jeni Tennison Consulting Ltd
- References: <BNEMICIEADHDDOIKLHNCCELCDJAA.elenz@xyzfind.com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Evan,
> <xsl:when test="count(.|../@*)=count(../@*)">
> <!-- built-in rule for attribute nodes -->
> <!-- btw: someone please give me a better way to
> test whether the current node is an attribute -->
> <xsl:value-of select="."/>
> </xsl:when>
In this context, you could use:
.. and not(self::node())
In fact the root node has already been filtered out, so you don't have
to test whether this node has a parent. The other thing to be aware of
is that this matches namespace nodes too. But if you're only dealing
with a conversion from the matching template version to a named
template version then you're fine because namespace nodes can't be
matched on.
> Is there anything that I'm missing here? Or is there anything that
> could not be converted in such a way?
xsl:apply-imports? - there's no equivalent for named templates. There
isn't a programmatic way of supporting that because you can't know
which next template is going to be processed without knowing what the
source is going to be.
I think you'd also start running into problems when you add support
for parameters in named templates - you could add them to your
applyTemplates template, but you'd have to take care of name clashes
(with possibly different default values) in it. But that's a fairly
minor issue - just requires a generate-id()-ed modifier on the name to
make them unique.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list