Re: [xsl] the document() in IE

Subject: Re: [xsl] the document() in IE
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Wed, 11 Jul 2007 16:56:54 +0200
David Carlisle wrote:
document('path', document('absolute path to current xslt'))
yes, but that's the same as

document(string('path'))

Finally: this new solution would work with document(), but not with xsl:import/include, which are relative to the xslt base always (and do not take parameters anyway).

usually when there are problems with uri resolution in xslt1 (I must say I've not really done this much in client side stylesheets) its because the base uri is not as expected, or not set at all. If the XSLt engine is reading a document directly then it's fairly clear what the base URI should be, but if the document (or the stylesheet) has previously been read into a DOM of some sort, perhaps manipulated with DOM scripting, and then passed as an in-memory tree to the XSLT processor, then the XSLT REC gives you noi guidance at all on what the base URI of the nodes will be, it is all completely implementation defined.

That's valuable info.
To do client-side XSLT transformations, one has generally two options: static inclusion using PI, or dynamic transformation using javascript. This second method requires you to load the DOM of the XSLT by using something similar to (many fuzz removed):


template = new ActiveXObject("MSXML2.XSLTemplate.3.0");
template.stylesheet = xslDomObject;    //holds DOM of XSLT file freethreaded
processor = template.createProcessor();

So, if I understand you correctly, when IE removes the path information (base uri) of the XSLT when it becomes a DOM object, it is still behaving conformant. Though I do find it a bit strange, because IE does keep record of the original URL with xslDomObject.url. And, actually, when you use any ActiveXObject, IE changes the path information to something relative to the containing HTML file (i.e., one other example is in CSS where you can use filters, which require ActiveX objects, and urls used in these filters are relative to the HTML file, not the CSS file....).

You say that my "workaround" is the same:

document('somepath', document('path to current xslt')) equals document('somepath')

but that is only true if the base uri of the current xslt has not been changed by the browser (or processor) to refer to something else then itself. Otherwise, it works as a resolution to resolve it back to the original uri (but that will not change the behavior for xsl:import/export still).

You can load the stylesheet directly from a url into the freethreaded dom object (unfort, IE has several ways of loading an XML dom and these are not interchangeable, i.e., the DOM returned from XHR is not usable as an XSLT DOM because is it not freethreaded which is why you must reload it), which should give you the advantage of keeping the base uri intact. This is not always possible (and to load a DOM from one style to another, you serialize it and reparse it: costly and, apparently, loosing base uri information).

Cheers,
-- Abel Braaksma

Current Thread