Michael Kay wrote:
An XSLT processor might notice at compile time that the stylesheet calls
document('') and might react by keeping a copy of the raw stylesheet entity
around for re-use at run-time. But it's much more likely, I think, that
document('') will be evaluated at run-time and cause a refetch.
David Carlisle wrote:
However if you are calling the transform from the javascript API, one
alternative to complicating the xslt with lots of nested
function-available tests is simply to modify the source (Or DOM) of the
stylesheet to use the MS namespace rather than the EXSLT one before
compiling the stylesheet.
Julian Reschke wrote:
if you need $foo to be a node-set. All this pain and extra case could
go away if Microsoft simply made "exslt:node-set" a synonym for
"msxsl:node-set".
A very interesting thread this has become!
Julian, there's a much larger and potentially more dangerous problem
with Microsoft's way of dealing with relative paths inside an XSLT. The
node-set problem very easily goes away by changing the DOM of the XSLT
just before you compile it (like David suggests, but until the wake of
Firefox 3.0 that won't help much). But it is much harder to remedy the
document('') problem.
It is known that document('') should reference the stylesheet itself
(see Michael's note) but for Microsoft that is not so easy. If you
compile your stylesheet from Javascript, then the base uri for Microsoft
is the base path of the html page calling the Javascript (!!!!). Which
means that document('') will *not* result in the XSLT file itself. And
if you have some auxiliary XML files relative to the XSLT location, and
the XSLT is not in the same location as your HTML, you are in trouble.
Problems get even weirder when you use xsl:import or xsl:include. The
href-attribute of these instructions are, in Microsoft's XSLT, not
relative to the XSLT, but again, relative to the hosting page (the HTML
page containing the Javascript that runs the XSLT).
The problems disappear when you use <?xsl-stylesheet ?>.
There's a Javascript fix I wrote for Sarissa which you can use without
the need of changing your stylesheet. Not sure it made it to a new
version of Sarissa (I haven't checked). The problem with fixing it is
when the document('') instruction becomes part of a more complex XPath,
or when the path specification of document('....') is made of a
combination of functions and instructions.
Cheers,
-- Abel Braaksma
PS: this path-problem is the same as the path problem Microsoft has when
using filters inside CSS. They don't take the base path of the CSS, but
the base path of the hosting HTML file.