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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--