xml - www - xslt transformation

Ruta relativa para xsl: import o xsl: include (7)

Estoy tratando de usar VBScript para hacer una transformación XSLT en un objeto XML.
El archivo XSL que estoy traduciendo incluye la directiva <xsl:import href="script.xsl"/> . Si utilizo la URL absoluta ( http://localhost/mysite/script.xsl ), importa bien la hoja de estilo; sin embargo, si uso la ruta relativa ( script.xsl ), informa "recurso no encontrado". Necesito poder portar esto entre un conjunto de máquinas, así que necesito poder usar el URI relativo. ¿Alguna sugerencia?

Notas:

El archivo VBScript está en http://localhost/myscript.asp
el primer archivo XSL está en http://localhost/mysite/styles.xsl
el segundo archivo XSL está en http://localhost/mysite/script.xsl
utilizando la ruta relativa mysite/script.xsl tampoco funciona

Apéndice:

Gracias a todos por sus respuestas. Cuanto más profundizo en el código que está haciendo esto, más extraño es. myscript.asp es una compilación bastante inusual de código. Lo que sucede es que styles.xsl se incluye en el resultado HTML de myscript.asp como un fragmento XML ( <xml src=...> ) y luego ese fragmento se carga como una hoja de estilo, utilizando VBScript, en el lado del cliente. Esta hoja de estilo se usa para transformar un fragmento XML que se recupera a través de XMLHTTP. Entonces el problema es el contexto de styles.xsl es el HTML en el lado del cliente y no tiene relación con donde está script.xsl .

Necesita una variable que defina approot o webroot cuando cargue archivos JS, Image o CSS.

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

o si tiene el valor en el XML,

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

¿Es posible que el "directorio actual" a los fines de la ruta relativa sea la ubicación de su página ASP, no su archivo XSL? En otras palabras, si aún no lo has hecho, puedes intentar:

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

El directorio actual para xsl: import, xsl: include, y la función document () es el directorio que contiene la transformación que los usa. Entonces, la directiva xsl: import que ha dicho que está utilizando debería estar funcionando.

Lo único que puedo pensar que podría afectar esto: si usa una ruta relativa, el archivo se lee directamente desde el sistema de archivos, mientras que si usa un URI absoluto, se está recuperando del servidor web. ¿Es posible que haya alguna configuración de seguridad que impida que los scripts lean archivos en este directorio?

@ Jon, creo que estás muy cerca ... pero no debería ser ...

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

... con una barra líder?

A menudo me encuentro con este problema porque hay una resolución URI personalizada que está utilizando una biblioteca que no puedo ver (o que no conozco porque no leí la documentación pertinente). No recuerdo si esta es una especificación o no, pero en el mundo de Saxon / java, el resolvedor de URI personalizado obtiene el primer intento de tratar de resolver los URI para las sentencias de inclusión / importación, así como la función document (). Si no puede resolver el URI, un resolvedor de URI predeterminado lo prueba, lo que generalmente nunca falla cuando el URI es absoluto.

Por lo tanto, es probable que haya algo en el motor de ASP que esté utilizando una resolución de URI basada en el contexto en función del contexto de la aplicación.

Me gustaría abordar esto ejecutando Sysinternals Process Monitor . Con esta herramienta ejecutándose, puede ver qué archivos intenta abrir su script, incluso si no existen.

Primer intento:

Traté de incluir script.xsl como otro fragmento xml y cambiar la declaración de importación en todas las formas que podía imaginar pero sin éxito.

Solución final:

Dado que la url absoluta para incluir script.xsl funcionó desde el principio, mi solución final fue convertir style.xsl a style.asp con el doctype correcto. En este archivo, pude recuperar el nombre del servidor, el protocolo y la ruta, y hacer eco de ellos en el lugar correcto en la declaración de importación utilizando asp. Luego, cuando este archivo se incluyó en mysscript.asp, tenía la url absoluta correcta para el servidor. Esto es un poco un truco, pero la única forma que encontré para resolver esta situación complicada.