Discussion :

[Loceka]

Bonjour,

Dans un fichier XML (XSL en fait) j'utilise une "librairie" externe me permettant d'ajouter des expressions régulières : http://www.exslt.org/regexp/index.html.

J'utilise donc le namespace "http://exslt.org/regular-expressions" tel que décrit dans leur doc et tout fonctionne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:regexp="http://exslt.org/regular-expressions">

Seulement je voudrais que mon code XSL fonctionne avec ou sans connexion internet. J'ai donc fait quelques tests :

Lorsque j'essaye d'accéder à l'URL donnée par ce namespace, je tombe sur une erreur 404.
J'ai donc essayé d'exécuter mon XSL sans internet (câble éthernet débranché). Résultat : il fonctionne sans problème.
Je me suis donc dit que cette URL était juste un nom et j'ai essayé de voir si en la modifiant dans mon code (en "http://exslt.org/regular-expression" par exemple), celui-ci fonctionnait toujours. Résultat : je me retrouve avec une erreur de parsing.

Le truc c'est que la seule chose que j'ai fait a été d'ajouter la ligne xmlns:regexp="http://exslt.org/regular-expressions".
Je n'ai téléchargé aucun schéma xsd, aucune dtd, ...

Alors je me demande comment ça fonctionne :
-> Est-ce que c'est mon parseur XSL (Firefox en l'occurrence) connaît d'office ce namespace et sait ce qu'il doit faire au cas où il le rencontre ?
-> Si c'est le cas, comment ça se passe lorsqu'on veut définir ses propres namespaces ?
-> Et si le parseur ne sait pas quoi faire lorsqu'il rencontre ce namespace, comment le lui dire ?

Voilà, si vous avez des réponses à apporter, vous êtes les bienvenus.

[Erwy]

Même si le namespace est une url cela n'a aucune importance, on ne la teste pas.
Par contre elle est utilisé comme une signature, donc dans ton cas, si tu fais appelle à une autre feuille

<xsl:import href="regexp.xsl" />

tu dois modifier son namespace de la même façon, histoire que les deux "signatures" soient bien identiques

[Loceka]

Le truc c'est que je n'ai pas trouvé leur page "regexp.xsl" et que j'avais décidé de tester sans, et ça marche.

Pour tester, il suffit de créer un fichier .xml contenant le code suivant et de l'ouvrir avec Firefox :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?xml version="1.0"?>
<?xml-stylesheet type="text/xml" href="#stylesheet"?>
<!DOCTYPE test [
<!ATTLIST xsl:stylesheet
  id	ID	#REQUIRED>
]>
 
<test>
	<mail>adresse@mail.com</mail>
 
	<xsl:stylesheet
			id="stylesheet"
			version="1.0"
			xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
			xmlns:regexp="http://exslt.org/regular-expressions">
		<xsl:template match="xsl:stylesheet" />
 
		<xsl:template match="/test/mail">
			<xsl:value-of select="regexp:replace(string(.), '.*?@', 'g', 'Loceka@')"/>
		</xsl:template>
	</xsl:stylesheet>
</test>

Il ne contient aucun import, juste le namespace.

[Erwy]

firefox fait partie des exception il supporte nativement mais partiellement certaines fonctions EXSLT :
https://developer.mozilla.org/en/EXSLT

Dans ce cas c'est bien le processeur xslt qui reconnait la chaine utilisée dans le namespcace et qui traduit les fonctions.Tu ne peux donc pas la modifier, mais il n'y a toujours pas d'accès à distance

[Erwy]

Le truc c'est que je n'ai pas trouvé leur page "regexp.xsl" et que j'avais décidé de tester sans, et ça marche.

dans les .zip présenté dans cette page

http://www.exslt.org/download.html

[thelvin]

Je me suis donc dit que cette URL était juste un nom

Yup. Ce sont en fait des Uniform Resource Identifiers, pas des Uniform Resource Locators. Nuance.

-> Est-ce que c'est mon parseur XSL (Firefox en l'occurrence) connaît d'office ce namespace et sait ce qu'il doit faire au cas où il le rencontre ?

Yup. La plupart des moteurs implémentent EXSLT au moins en partie, tout simplement parce qu'ils reconnaissent que c'est pratique.

-> Si c'est le cas, comment ça se passe lorsqu'on veut définir ses propres namespaces ?
-> Et si le parseur ne sait pas quoi faire lorsqu'il rencontre ce namespace, comment le lui dire ?

Les fonctions de ces namespaces sont alors inconnues.

À noter que les moteurs permettent souvent d'utiliser des extensions qu'il faut leur fournir avec, soit sous forme de langage de script dans la feuille XSLT, soit sous forme de plugin accessible au moteur. Dans ces deux cas-là, on utilise en effet des namespaces particuliers pour pointer vers l'extension, et ils peuvent devoir respecter une syntaxe, dans ce cas-là ils sont aussi une URL.

Il faut bien comprendre que les moteurs XSLT ne sont pas tenus d'avoir un tel mécanisme d'extension, ni d'embarquer un moteur JavaScript, python, Ruby, Perl ou autre. Quant aux extensions sous forme de plug-in, de toute façon un plug-in Java ne risque pas de marcher avec un moteur .Net. Sans compter qu'on ne peut aps compter sur sa présence si on ne l'a pas installé et qu'on ne peut pas le fournir avec la feuille. Et de toute façon la norme ne définit pas de mécanisme universel pour les désigner.

De ce que j'en ai vu, il existe des implémentations EXSLT qu'on peut inclure comme extension au cas où le moteur ne l'ait pas déjà : dans ce cas-là ça s'intègre exactement comme des extensions qu'on a fait soi-même dans son garage. Ce qui est bien moins pratique et moins standard, raison pour laquelle les moteurs préfèrent l'inclure nativement.

[Loceka]

Ok je comprends mieux dans ce cas.

Merci bien pour ces réponses, ça m'avait complètement paumé.

PS :
Je devais pas avoir les yeux en face des trous quand j'ai cherché leur fichier à inclure, il est relativement visible sur le site...

D'ailleurs, même en l'important et en appliquant une feuille de style externe à mon XML (le tout en un c'était pour la commodité de l'exemple), ça ne fonctionne ni sous Opera (10) ni sous IE (8)...