Re: [xsl] XSLT 1.0 support in browsers, as of June 2008

Subject: Re: [xsl] XSLT 1.0 support in browsers, as of June 2008
From: Julian Reschke <julian.reschke@xxxxxx>
Date: Wed, 18 Jun 2008 17:28:21 +0200
Michael Ludwig wrote:
Julian Reschke schrieb:
<xsl:template match="text()[not(ancestor::artwork)]">

What's the problem with this particular expression?

For every text node this template applies to, a check must be performed to determine if there is any artwork element node on the ancestor axis. This is probably not terribly bad, but it doesn't look efficient either.

Yes, that's what it's supposed to do :-).

I haven't examined your program, but there might be a way to code this
more efficiently, maybe by using an artwork mode or an artwork parameter,
so the information is available at each step and does not have to be
looked up 3464 times, as in rfc2616.xml.

That's certainly possible, but it would mean that lots of code needs to be duplicated (mode), or rewritten to use named templates (which I'd like to avoid to keep the code readable).

There probably isn't any problem with this one expression. Your heavy
use of the descendant axis is likely to involve much more scanning,
especially when started at the root. The processor has to search the
entire document, and if the document has a lot of nodes, this may take a
long time, even growing exponentially.

grep -E '([^:]//|descendant)' rfc2629.xslt

I do understand that this is expensive, but it's sometimes a result of the XML vocabulary being transformed. xsl:key can help in same cases, but it's not always possible to use it, for instance because it doesn't work when parts of the content do not originate from same the source file.

BR, Julian

Current Thread