Relative path for xsl:import or xsl:include

Question

I am trying to use VBScript to do an XSLT transform on an XML object.
The XSL file I'm translating includes the <xsl:import href="script.xsl"/> directive. If I use the absolute URL (http://localhost/mysite/script.xsl), it imports the style sheet fine; however, if I use the relative path (script.xsl) it reports "resource not found." I need to be able to port this amongst a set of machines, so I need to be able to use the relative URI. Any suggestions?

Notes:

• VBScript file is at http://localhost/myscript.asp
• first XSL file is at http://localhost/mysite/styles.xsl
• second XSL file is at http://localhost/mysite/script.xsl
• using the relative path mysite/script.xsl also does not work

Addendum:

Thanks, everyone, for your answers. The more I dig into the code that is doing this, the stranger it is. myscript.asp is a rather unusual compilation of code. What happens is styles.xsl is included in the HTML output of myscript.asp as an XML chunk (<xml src=...>) and then that chunk is loaded as a stylesheet, using VBScript, on the client side. This stylesheet is then used to transform an XML chunk that is retrieved via XMLHTTP. So the problem is the context of styles.xsl is the HTML on the client side and has no relation to where script.xsl is.

Solution 1

First Attempt:

I tried including script.xsl as another xml chunk and changing the import statement in every way I could imagine but without success.

Final solution:

Since the absolute url for includeing script.xsl worked from the beginning, my final solution was to convert style.xsl to style.asp with the correct doctype. In this file I was then able to retrieve the server name, protocol and path and echo them into the right place in the import statement using asp. Then, when this file got included in mysscript.asp, it had the correct absolute url for the server. This is a bit of a hack but the only way I found to solve this rather convoluted situation.

Solution 2

@Jon I think you are very close... but shouldn't it be...

<xsl:import href="/mysite/script.xsl"/>

...with a leading slash?

Solution 3

I would tackle this by running Sysinternals Process Monitor. With this tool running, you can actually see what files your script tries to open, even if they don't exist.

Solution 4

The current directory for xsl:import, xsl:include, and the document() function is the directory containing the transform that uses them. So the xsl:import directive that you've said you're using ought to be working.

The only thing I can think of that might affect this: if you use a relative path, the file's being read directly from the file system, while if you use an absolute URI, it's being retrieved from the web server. Is it possible that there's some security setting that's preventing scripts from reading files in this directory?

View more solutions

Comments

[astonia]

It does not work for xsl:import, it works for general elements such as <style> or <javascript> etc.