Re: [xsl] the document() in IE

[Abel Braaksma <abel.online@xxxxxxxxx>]

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