Poser un point d'arrêt dans une feuille de style XSLT

Dans un langage impératif, un point d'arrêt suspend une ligne. En XSLT, il suspend le traitement d'un nœud par un modèle — et cette différence explique la quasi-totalité des points d'arrêt qui semblent ignorés.

Un point d'arrêt posé sur un modèle qui ne s'applique à aucun nœud ne se déclenche jamais. Ce n'est pas une panne de l'outil : c'est l'information que vous cherchiez, arrivée sous une forme qu'on ne reconnaît pas.

La séquence qui marche tient en trois gestes :

1. poser l'arrêt sur le xsl:template, jamais sur le xsl:value-of qu'il contient ;
2. lancer, et lire le nœud courant au moment de l'arrêt ;
3. si l'arrêt ne vient pas, ne pas chercher plus loin dans le corps du modèle — le match est en cause.

Pourquoi « sur le modèle » et pas « sur la ligne »

Les instructions d'un modèle ne s'exécutent que si le modèle a été sélectionné. Poser l'arrêt à l'intérieur revient à poser une question qui suppose déjà la réponse : si le modèle ne s'applique pas, l'arrêt intérieur ne dira rien, et son silence sera lu comme un silence de l'outil.

L'arrêt sur xsl:template distingue les deux : il se déclenche une fois par nœud traité. Zéro déclenchement signifie zéro nœud, ce qui est un fait, pas une absence d'information.

Quand l'arrêt ne vient jamais

<xsl:template match="ligne[@type='remise']">
  <xsl:value-of select="montant"/>
</xsl:template>

Ce modèle ne se déclenche que sur les ligne portant exactement type="remise". Trois raisons courantes qu'aucune n'existe :

• le prédicat est plus étroit que les données — type="Remise", ou l'attribut est absent ;
• le document déclare un espace de noms que le match ignore, cas détaillé dans les cinq causes silencieuses d'un XSLT vide ;
• aucun xsl:apply-templates ne descend jusqu'à ces nœuds, et le modèle ne peut pas être choisi pour un nœud qu'on ne lui présente pas.

⚠️ Un quatrième cas trompe plus que les trois autres : le modèle est candidat, mais un autre gagne. À priorité égale, c'est le dernier déclaré qui l'emporte ; une feuille importée peut donc prendre la main sans que rien ne le signale. Un arrêt posé sur les deux modèles concurrents tranche en une exécution.

Lire le nœud courant, pas le numéro de ligne

À l'arrêt, la question utile n'est pas « où suis-je dans le fichier » mais « sur quoi suis-je ». Le chemin du nœud courant répond aux deux à la fois : il dit quel nœud est traité, donc quel chemin de sélection l'a amené là.

C'est la même lecture que celle des variables : ce qu'on veut voir est un état, pas une position. Une variable qui paraît vide à cet endroit a ses propres causes, décrites dans une variable XSLT vide : les trois causes qu'on ne voit pas.

Les conditions, et un piège qui va dans l'autre sens

Une condition XPath restreint l'arrêt aux passages qui vous intéressent — utile sur une boucle de mille nœuds dont un seul pose problème.

🔴 Attention au sens de la panne. Une condition qui ne peut pas être évaluée ne rend pas le point d'arrêt muet : elle le fait s'arrêter à tous les passages. Le symptôme d'une condition fautive est donc un point d'arrêt qui s'arrête trop souvent, jamais un point d'arrêt ignoré.

⚠️ C'est l'inverse de l'intuition, et c'est ce qui fait perdre du temps : on cherche pourquoi « ça ne s'arrête pas » alors que le problème est qu'on n'a pas remarqué que ça s'arrête partout. Testez l'expression dans un évaluateur XPath avant de la poser comme condition.

Ce que cet article ne couvre pas

• les règles par défaut : elles ne sont écrites nulle part, on ne peut donc pas y poser d'arrêt — leur trace est du texte recopié en sortie ;
• un arrêt à l'intérieur d'une expression XPath : la granularité s'arrête à l'instruction ;
• les feuilles en streaming, où l'arbre n'est pas disponible à l'arrêt ;
• les points d'arrêt sur variable, qui répondent à une autre question — non plus quand, mais qui écrit.

Le chapitre déboguer du manuel traite ces deux derniers points, ainsi que l'avancée pas à pas une fois l'arrêt obtenu.