Chemin relatif pour xsl: import ou xsl: include

Question

J'essaie d'utiliser VBScript pour effectuer une transformation XSLT sur un objet XML.
Le fichier XSL que je traduis inclut la directive <xsl:import href="script.xsl"/>. Si j'utilise l'URL absolue (http://localhost/mysite/script.xsl), la feuille de style est importée avec précision. Toutefois, si j'utilise le chemin relatif (script.xsl), il indique " ressource non trouvée. " Je dois être capable de porter cela sur un ensemble de machines, donc je dois pouvoir utiliser l'URI relatif. Des suggestions?

Notes:

• Le fichier VBScript est à http://localhost/myscript.asp
• le premier fichier XSL est à http://localhost/mysite/styles.xsl
• le deuxième fichier XSL est à mysite/script.xsl
• utiliser le chemin relatif myscript.asp ne fonctionne pas non plus

Addendum:

Merci à tous pour vos réponses. Plus je fouille dans le code qui fait cela, plus il est étranger. styles.xsl est une compilation de code assez inhabituelle. Ce qui se passe est que <xml src=...> est inclus dans la sortie HTML de <=> sous forme de bloc XML (<=>), qui est ensuite chargé en tant que feuille de style, à l'aide de VBScript, côté client. Cette feuille de style est ensuite utilisée pour transformer un bloc XML récupéré via XMLHTTP. Le problème est donc que le contexte de <=> est le code HTML côté client et n’a aucune relation avec où <=> est.

Answer 1

Première tentative:

J'ai essayé d'inclure script.xsl dans un autre fragment xml et de modifier l'instruction d'importation de toutes les manières possibles mais sans succès.

Solution finale:

Comme l'URL absolue pour l'inclusion de script.xsl a fonctionné dès le début, ma solution finale a été de convertir style.xsl en style.asp avec le doctype correct. Dans ce fichier, j'ai ensuite pu récupérer le nom du serveur, le protocole et le chemin d'accès, puis les faire écho au bon endroit dans la déclaration d'importation en utilisant asp. Ensuite, lorsque ce fichier a été inclus dans mysscript.asp, il contenait l’URL absolue correcte pour le serveur. C’est un peu un bidouillage, mais le seul moyen que j’ai trouvé de résoudre cette situation plutôt compliquée.

Answer 2

Le répertoire en cours pour xsl: import, xsl: include et la fonction document () est le répertoire contenant la transformation qui les utilise. Donc, la directive xsl: import que vous avez dite que vous utilisez doit fonctionner.

La seule chose à laquelle je peux penser qui pourrait affecter ceci: si vous utilisez un chemin relatif, le fichier est lu directement à partir du système de fichiers, alors que si vous utilisez un URI absolu, il est extrait du serveur Web. Est-il possible qu'un paramètre de sécurité empêche les scripts de lire les fichiers de ce répertoire?

Answer 3

@Jon Je pense que vous êtes très proche ... mais ne devrait-il pas en être ainsi ...

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

... avec une barre oblique?

Answer 4

Pour résoudre ce problème, exécutez Sysinternals Process Monitor . Avec cet outil en cours d’exécution, vous pouvez réellement voir quels fichiers votre script tente d’ouvrir, même s’ils n’existent pas.

Answer 5

Est-il possible que le " répertoire actuel " Pour les besoins du chemin relatif peut être l'emplacement de votre page ASP, pas votre fichier XSL? En d’autres termes, si vous ne l’avez pas déjà fait, essayez:

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

Answer 6

Je rencontre souvent ce problème parce qu’une bibliothèque que je ne vois pas utilise un résolveur d’URI personnalisé (ou que je ne connais pas parce que je n’ai pas lu la documentation pertinente). Je ne me souviens pas si cela Spécifique ou non, mais dans le monde saxon / java, le résolveur d’URI personnalisé est le premier à tenter de résoudre les URI des instructions include / import ainsi que de la fonction document (). S'il ne parvient pas à résoudre l'URI, un résolveur d'URI par défaut lui donne la possibilité d'essayer, ce qui ne manque généralement jamais lorsque l'URI est absolu.

Donc, c'est probablement quelque chose dans le moteur ASP qui utilise un résolveur d'URI basé sur le contexte basé sur le contexte de l'application.

Answer 7

Vous avez besoin d'une variable qui définit l'approche ou la racine Web lors du chargement de fichiers JS, Image ou CSS.

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

ou si vous avez la valeur dans le XML,

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