Xsl relative path for xsl:import or xsl:include

Question

I am trying to use VBSctipt 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 href (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 their answers but 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 a 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 a 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.

Answer 1

Is it possible that the "current directory" for purposes of the relative path might be the location of your ASP page, not your XSL file? In other words, if you haven't already, you might try:

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

Answer 2

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?

Answer 3

I just knocked together the same setup as described and didn't encounter any problems. The second XSL imports just fine using a relative path.

If you could post the source to myscript.asp that would be helpful.

Cheers Kev

Answer 4

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

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

...with a leading slash?

Answer 5

I often run into this problem because there is a custom URI resolver being used by a library I can't see (or don't know about because I didn't read pertinent documentation.) I can't remember if this is spec or not but in the Saxon/java world, the custom URI resolver gets first crack at trying to resolve URI's for include/import statements as well as the document() function. If it can't resolve the URI, a default URI resolver gives it a try, which usually never misses when then URI is absolute.

So, it's probably something in the ASP engine that is using a context driven URI resolver based on the app context.

Answer 6

You need a variable that defines the approot, or webroot when loading JS, Image or CSS files.

 <xsl:import href="{$approot}/somedir/script.xsl"/>

or if you have the value in the XML,

 <xsl:import href="{/root/@approot}/somedir/script.xsl"/>

Answer 7

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.

Answer 8

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.