Comprendre XSLT

A quoi sert XSLT ?

Les avantages de XSLT

1. être transformé en XML "propre" (c'est-à-dire reflétant la structure intrinsèque de l'information qu'il contient et non plus une présentation plus ou moins arbitraire de cette information)
2. être secondairement, selon les besoins, transformé en fichiers affichables sur quelque support que ce soit (papier, microordinateur, téléphone portable...)

Les caractéristiques de XSLT

• c'est un langage déclaratif et non procédural. Ce qui revient à dire qu'à la différence d'un langage de programmation classique, il ne spécifie pas le comment ? (les algoritmes) :  il se contente de déclarer le quoi ? Par exemple :
• que tout ou partie des balises <para> présentes dans le XML source sont à remplacer dans le HTML cible par des balises <p>
• que telle partie de l'arbre XML source doit être reproduite telle quelle dans l'arbre XML résultat, ou bien déplacée, ou bien encore dupliquée...
• il est lui-même écrit en XML. Ce qui veut dire qu'il pourra être à son tour  transformé par une nouvelle feuille de style XSLT, et ainsi de suite, à l'infini ! Ou bien encore qu'il pourra être manipulé à l'aide de tout langage de programmation qu'on voudra, pourvu que ce langage implémente l'interface Document Object Model (DOM)...

Un peu d'histoire : de  XSL à XSLT et XSL-FO

Langages "orientés-contenu" et "orientés-présentation"

XML et feuilles de style

En XML une feuille de style stricto sensu n'est bien entendu pas suffisante. Si votre XML contient, par exemple, une bibliographie, vous pouvez certes l'associer directement à un feuille de style CSS qui vous permettra, par exemple, d'associer à l'élément auteur la police Verdana 14 points et la couleur teal. Mais une telle feuiIle de style CSS ne vous permettra pas de spécifier :

• que vous voulez que la bibliographie soit présentée sous la forme d'un tableau, ou sous la  forme d'une liste ;
• qu'elle doit être classée selon tel ou tel critère ;
• que les différentes informations relatives à un même livre (auteur, titre, éditeur...) devront apparaître dans tel ou tel ordre, avec tels ou tels séparateurs, etc.

• non seulement les objets de présentation génériques,  tels que listes et tableau -- et à l'intérieur de ceux-ci l'italique, les sauts de ligne, etc -- qui vont être mis en oeuvre pour afficher son contenu ;
• mais encore, et surtout, la façon dont les parties constitutives du contenu (en l'occurence les livres et à l'intérieur de ceux-ci les auteurs, les titres etc.) vont être distribuées à l'intérieur de ces objets génériques -- dans quel ordre, selon quel classement, etc.

Dans le second cas on parlera de transformation.

Cette analogie boiteuse qui avait été faite au départ avec les feuilles de styles stricto sensu explique que dans les premiers projets de spécification du W3C le langage de transformation propre à XML que nous appelons aujourd'hui XSLT a pu être mélangé, dans un projet des spécification unique baptisé à l'époque XSL (Extensible Style Language), à un tout autre langage. Cet autre langage étant, lui, destiné à définir des objets de formattage plus riches que ceux de HTML puisque destinés à de présenter un contenu XML sur les supports les plus variés (écran, mais aussi papier...)

Désormais les choses sont beaucoup plus claires, puisque les deux langages ont été séparés. L'un est devenu XSL Transformations (XSLT) et l'autre XSL-Formatting Objects (XSL-FO). Le premier seul est à l'heure actuelle arrivé au stade de spécification du W3C.

L'espace de nom (namespace) de XSL(T)

Deux avantages :

• Le préfixe xsl: va permettre de différentier à l'intérieur de la feuille de style les éléments qui appartiennent au langage XSLT de ceux qui devront apparaître dans le résultat final (les "éléments de résultat litéral")
• L'URI spécifiée dans la déclaration de l'espace de nom va éventuellement permettre de distinguer plusieurs implémentations de XSLT. (C'est ce que fait en particulier le nouveau moteur XSLT (MSXML3) de Microsoft et qui lui permet de traiter aussi bien des feuilles de style "IE5 natif" que XSLT 1.0)

<toto:transform xmlns:toto="http://www.w3.org/1999/XSL/Transform" version="1.0">
....
</toto:transform>

La philosophie des "règles modèle" (templates)

Qu'est-ce qu'une règle modèle (template)?

Comparaison avec les règles CSS

On se rappelle qu'une feuille de style CSS se compose d'un certain nombre de règles (rules). Chacune de ces règles se composant :

1. d'un sélecteur (ex. p.commentaire em, qui signifie "les balises <em> contenues dans une balise <p> de classe commentaire")
2. d'une ensemble de déclarations du type propriété (ex. color) - valeur (ex. yellow)

Mais il est important de comprendre qu'une feuille CSS ne fait que décorer un arbre HTML ; elle ne le modifie pas. Une règle CSS ne fait qu'ajouter des caractéristiques nouvelles (positionnement, couleurs, polices de caractères, etc.) à un objet de formattage qui aurait été généré de toutes façons, CSS ou pas. En conséquence une régle CSS vide (ne contenant aucune déclaration) sera simplement sans effet : lorsqu'une balise satisfera aux conditions exprimées par son sélecteur, l'objet de formattage associé sera généré exactement comme si la règle n'existait pas.

Autre caractéritistique des feuilles de style CSS : l'ordre d'apparition des règles dans la feuille de style est indifférent.

Enfin, lorsqu'une balise satisfait aux conditions exprimées par les sélecteurs de plusieurs régles, l'objet de formattage associé va être affecté de la somme des caractéristiques spécifiées par les déclarations listées dans ces différentes règles. En cas de conflit entre des déclarations, un mécanisme de priorité entrera en jeu : la déclaration qui est contenue dans la règle la plus spécifique (ex. p.commentaire em est plus spécifique que em) va l'emporter.

A première vue les règles modèles de XSLT ressemblent fort aux règles CSS :

1. elles comportent un sélecteur (ici un chemin de localisation XPath) qui va définir à quel(s) noeud(s) (éléments, attributs...) la règle s'applique ;
2. leur ordre d'appartion dans la feuille de style est indifférent ;
3. il existe un mécanisme de priorités pour régler les conflits entre règles s'appliquant à un même noeud.

1. Une régle modèle n'a pas pour fonction d'ajouter des caractéristiques nouvelles à un résultat prédéterminé : le résultat dépend entièrement de la règle modèle. Ainsi une régle modèle vide ne va générer aucun résultat. Lorsqu'un noeud (élément, attribut...) satisfera aux conditions exprimées par son sélecteur, aucun contenu correspondant (ni balise, ni attribut, ni texte) ne sera généré dans le fichier résultat : la règle modèle se comportera alors comme un filtre.
2. Caractéristique très importante : pour produire un résultat une règle modèle doit impérativement avoir été invoquée par une autre règle modèle.
3. Enfin, en cas de conflit une seule règle modèle s'appliquera (par application également d'un mécanisme de priorités), à l'exclusion de toutes les autres.

Note. En réalité il  n'existe pas de feuille de style XSLT véritablement vide, puisque la spécification XSLT a prévu qu'un certain nombre de règles modèles, dites régles modèles "internes", doivent exister par défaut dans toute feuille de style. Ces règles modèles, explicitées plus bas, vont faire qu'une feuille de style "vide" va néanmoins produire un résultat. A titre anecdotique on peut rappeler que le moteur de transformation XSLT d'"IE5 natif" ne respecte  pas cette exigence, ce qui fait que ce moteur produit bien un résultat nul en réponse à une feuille de style XSLT vide.

De ce qui précède on retiendra deux choses essentielles :

• La feuille de style XSLT ressemble à la feuille de style CSS en ce qu'elle est constituée comme elle d'une suite de déclarations, d'ordre indifférent, dont chacune comporte un filtre (sélecteur pour CSS, chemin de localisation XPath pour XSLT) servant à distinguer les constituants du fichier source (éléments HTML pour CSS, noeuds XML pour XSLT) auxquels la déclaration s'applique de ceux auxquels elle ne s'applique pas.
• La feuille de style XSLT diffère de la feuille CSS en ce que ses différentes déclarations (règles modèles) doivent s'appeler les unes les autres, exactement comme dans un langage de programmation procédural un programme principal peut appeller des sous-programmes, qui eux-mêmes peuvent appeler des sous-programmes, etc. C'est ce mécanisme qui va permettre à la feuille XSLT de générer un arbre résultat éventuellement très différent de l'arbre source, alors que la feuille CSS ne sait que décorer un arbre source dont elle est bien incapable de modifier la structure.

• Il faut bien une régle modèle "principale", qui soit appelée en premier et qui puisse ensuite donner la main aux autres. Cette règle principale est celle qui est associée à la racine (notée "/" dans le langage XPath) du document XML (nous dirons que cette règle est positionnée sur la racine du document). Cette première règle va en général en appeler d'autres qui auront toutes pour caractéristiques d'être elles aussi positionnées sur un noeud, ou un ensemble de noeuds précis du document XSLT. Il faut bien en effet avoir présent à l'esprit qu'à tout moment de l'exécution d'une feuille XSLT le moteur de transformation va se trouver positionné sur deux  documents/fichiers différents :
1. dans le programme que constitue la feuille de style : dans une règle modèle précise, et sur une instruction précise de ladite règle modèle ;
2. dans les données que constitue le fichier XML source : sur un noeud (élément, attribut...) précis.
• Contrairement à ce qui se passe dans un langage procédural, on a ici un mécanisme "piloté par les données" (data driven). En ce sens que l'appel  n'est pas un appel direct à une règle modèle (Note. un tel mécanisme existe en XSLT mais il y joue un rôle secondaire : c'est celui des règles modèle nommées), mais passe par deux étapes successives:
• Rechercher dans le fichier XML les noeuds satisfaisant une condition précise (<xsl:apply-templates select="motif XPath"/>). Par défaut  (absence de l'attribut "select") on recherche les éléments fils du noeud sur lequel on se trouve actuellement positionné.

Note. Le motif XPath consiste essentiellement en un adressage, soit absolu soit relatif au noeud XML sur lequel on se trouve actuellement positionné, assorti éventuellement de conditions (dites prédicats).
• Constituer la liste de ces noeuds qui devient la liste de noeuds courante, et éventuellement ordonner cette liste selon certains critères.
• Se positionner successivement sur chacun des noeuds de cette liste (qui devient alors provisoirement le noeud courant), et pour chacun de ces noeuds  :
• rechercher les règles modèles s'appliquant à ce noeud ;
• s'il y en a plusieurs déterminer la plus prioritaire ; et enfin
• invoquer cette règle.

• à l'emplacement du fichier cible où l'on se trouvait lorsque le modèle a été invoqué
• en exploitant le fichier source -- en adressage absolu ou relatif à partir du noeud courant.

• soit direct (<xsl:value-of...>)
• soir par appel d'une éventuelle règle modèle susceptible de s'y appliquer (<xsl:apply-templates.../>)

Qu'est ce qu'un noeud XML ?

1. la racine du document -- l'objet qui englobe l'ensemble du document : à ne pas confondre avec l'élément (balise) de plus haut niveau, qui en est le fils, et qui est parfois appelé élement racine. En XPath la racine du document est représentée par le symbole /. Si une feuille XSLT déclare des règles modèles il est obligatoire qu'elle en déclare au moins une  ayant pour cible la racine (mais il est possible de construire des feuilles XSLT ne déclarant aucune règle modèle et se comportant comme une unique règle modèle).
2. les éléments ou balises -- de loin les noeuds les plus importants. Ce sont les "branches" de l'arbre XML.  En XPath ils sont symbolisés individuellement par leur nom, tout simplement, et collectivement par * (si le spécificateur d'axe qui précède n'est pas attribute:: ou namespace::)
3. les noeuds textuels -- les "feuilles" de l'arbre XML, où réside l'information "de base". Les noeuds textuels sont ce qui reste à l'intérieur d'une balise quand on a retiré les balises filles et leur contenu. Ils sont eux aussi considérés comme des noeuds "fils" de la balise qui les contient. En XPath ils sont symbolisés  par text(). Note. Les valeurs d'attribut ne sont pas des noeuds textuels
4. les attributs -- les informations complémentaire inscrites (sous la forme étiquette="valeur") à l'intérieur même des balises. En XPath ils sont symbolisés individuellement par leur nom précédé de attribute:: ou de @, et collectivement par attribute::node() ou attribute::*, ou @*. Ils ne sont pas considérés comme des noeuds fils de l'élément qui les contient.
5. enfin, et pour mémoire : les instruction de traitement ("processing instructions"), les commentaires, et les espaces de nom ("namespaces"). En XPath ils sont symbolisés par processing-instruction('cible'), comment() et namespace::préfixe

Note. On lit parfois que node() désignerait collectivement tous les types de noeud à l'exception des attributs. C'est inexact. La confusion vient du fait que dans une étape de localisation node() non précédé d'un spécificateur d'axe est une abréviation de child::node(), et  désigne donc tous les noeuds fils du noeud contextuel. Or les attributs n'en font pas partie. Pour les désigner collectivement il convient donc d'écrire attribute::node() ou attribute::* ou @*

Comment les règles modèles accèdent aux données XML : les chemin de localisation ou motifs XPath

Qu'est-ce que le chemin de localisation/motif ? C'est, si vous voulez, l'objet que vous donnez à flairer à votre limier pour qu'il piste un gibier bien particulier... Ou si vous préférez des lunettes dont vous chaussez votre moteur de transformation et qui le rendent aveugle à tous les noeuds à l'exception de ceux, bien spécifiques, qui devront être sa proie unique. Le chemin de localisation s'écrit à l'aide du langage XPath déjà mentionné.

La syntaxe des chemins de localisation : les "étapes de localisation"

• une ou plusieurs étapes de localisation XPath, séparées entre elles par le symbole /. A son tour chacune de ces  étape de localisation est constituée de, dans l'ordre :

1. un axe (par défaut l'axe implicite est child), suivi du séparateur :: , suivi de
2. un test de noeud, suivi de
3. de zero à n  prédicats, encadrés chacun par [ ].

• Exemple de chemin de localisation absolu : //biblio/*/livre/auteur va rendre le moteur de transformation aveugle à tout ce qui n'est pas une balise <auteur>, fille d'une balise <livre>, elle-même petite fille d'une balise <biblio>", laquelle pourra se trouver n'importe où à l'intérieur de l'arbre XML.
• Exemple de chemin relatif : ../adresse va limiter les recherches aux balises <adresse> qui sont filles de la balise mère de la balise "contextuelle" (celle sur laquelle on est actuellement positionné) -- autrement dit les soeurs de la balise contextuelle qui seraient des balises <adresse>, et la balise contextuelle elle-même au cas où elle serait une balise <adresse>.

Symboles et abréviations utilisés dans la syntaxe XPath des chemins de localisation

Les spécificateurs d'axe

Les tests de noeud

Les filtres ou prédicats

Quelle est la syntaxe d'une règle modèle ?

Que fait une règle modèle une fois qu'elle est activée ?

Si vous souhaitez que le modèle fasse quelque chose, ne serait-ce que rendre la main à d'autres modèles, eh bien il faut le lui demander explicitement !

Vous pouvez, par exemple lui demander de simplement remplacer les balises <para> et tout ce qu'elles contiennent par le texte "trouvé !". En ce cas il vous suffira d'écrire :

Alors, comment faire ? C'est ici qu'apparaît tout l'intérêt de l'instruction "reine" de XSLT : <xsl:apply-templates /> .

Que fait cette instruction ? Eh bien, on l'a vu, elle permet à la règle modèle active de demander à la cantonade si, par hasard, d'autres règles modèles ne voudraient pas reprendre le travail là où elle l'a laissé... Et si il ne s'en trouve pas ? Eh bien tant pis, elle s'en désintéresse !

Vous l'aurez compris, XSLT est basé sur la division du travail et la coopération. En XSLT comme dans la vie, la division du travail et la coopération sont un peu difficiles à mettre en place et à faire fonctionner. Mais, toujours comme dans la vie, elles se révèlent une fois en place extrêmement efficaces et d'un fonctionnement très souple.

Prenez par exemple l'instruction que nous avons écrite ci-dessus dans notre modèle :

• le cas où la balise <para> ne contient que du texte
• le cas ou elle contient des balises filles -- auquel cas il faudra bien entendu que des règles modèles spécifiques aient été définies pour traiter ces balises, du genre :

• des règles modèles capturant spécifiquement  les balises filles existent et leur passent la main en faisant à leur tour <xsl:apply-templates />
• ou bien que l'on ait défini une règle modèle générique qui, faute de de modèles plus spécifique, va capturer les balises filles et leur faire passer la main à leurs propres filles et ainsi de suite. Cette règle modèle générique "parcoureuse d'arbre" à l'allure suivante :
<xsl:template match="*">
<xsl:apply-templates />
</xsl:template>

• soit avoir des règles modèles qui ciblent tous les noeuds intermédiaires entre la racine du document source et ce noeud particulier, même si vous n'avez aucun traitement particulier à effectuer sur ces noeuds, auquel cas ces règles modèles ne contiendront que le fameux <xsl:apply-templates />
• soit effectuer un saut direct à partir d'une autre règlemodèle, en utilisant l'instruction <xsl:apply-templates select="chemin" />

Les règles modèles "internes"

Note 1. Les valeurs d'attribut ne seront pas reproduites parce que la première règle ne fait pas parcourir les attributs. Il y faudrait un <xsl:apply-templates select="@* | node()" />. Puisque :

1. <xsl:apply-templates /> est équivalent à <xsl:apply-templates select="node()" /> ;
2. node() est en fait l'abréviation de child::node() ;
3. les attributs ne sont pas considérés comme "enfants" de l'élément qui les comporte.

1. comme rappelé ci-dessus, <xsl:apply-templates /> est équivalent à <xsl:apply-templates select="child::node()" /> ;
2. les noeuds textuels sont considérés comme "enfants" de l'élément qui les comporte.

La règle modèle de transformation "à l'identique"

Question. Pourquoi "@* | node()" et non pas seulement select="node()" ? Réponse ci-dessus.
 

Noeud courant, liste de noeuds courante, et noeud contextuel

Rappelons que ces instructions "de travail" peuvent être de deux sortes :

• Instructions d'exploitation directe du fichier cible. Ainsi, dans l'exemple précédent, l'instruction <xsl:value-of select="."> va reproduire les noeuds textuels descendants de la balise <para> trouvée par le modèle. Ces instructions ne modifient en général pas la liste de noeuds courante et le noeud courant. Une exception est l'instruction de répétition <xsl:for-each...>. Cette instruction va avoir pour effet de créer provisoirement une nouvelle  liste de noeuds courante, dont les éléments vont devenir, chacun à leur tour, le nouveau noeud courant. A la fin de ce processus la liste de noeud courante et le noeud courant vont redevenir ce qu'ils étaient au début.
• Instruction d'invocation d'autres règles modèles. De même, si dans l'exemple précédent, l'instruction <xsl:value-of select="."> est remplacée par l'instruction <xsl:apply-templates />, celle-ci va passer la main à d'autres règles modèles à la condition que celles-ci capturent (s'appliquent à) des noeuds fils de la balise <para>  trouvée par le modèle. Chaque règle modèle ainsi invoquée va bien entendu, à son tour, constituer sa propre liste de noeuds courants et itérer à l'intérieur de celle-ci.

Retour à la page d'accueil.