Saxon HE, PE, EE : ce que l'édition gratuite ne fait pas
Saxon HE couvre XSLT 2.0 et 3.0. Ce qu'elle ne fait pas se découvre en général au pire moment, sur une feuille qui fonctionnait ailleurs.
Saxon-HE, l'édition gratuite, couvre XSLT 3.0, XPath 3.1 et XQuery 3.1. Pour la très grande majorité des transformations, elle suffit — et croire l'inverse coûte plus cher que la licence qu'on croit devoir acheter.
Ce qu'elle ne fait pas tient en quatre points, et 🔴 trois d'entre eux se voient à la lecture de la feuille, avant d'avoir rien exécuté :
| Fonction | HE | Comment cela se manifeste |
|---|---|---|
| validation par schéma XSD | non | requires a schema-aware processor |
exécution en flux (xsl:stream) | non | erreur statique, à la compilation |
| compilation en octets, parallélisme | non | aucun message, seulement la lenteur |
| appel réflexif de méthodes Java | non | Cannot find a matching function |
⚠️ La troisième ligne est la seule qui ne se signale pas, et c'est celle qui fait perdre le plus de temps : rien n'échoue, la transformation est simplement plus lente, et le temps perdu est attribué à la feuille de style. On optimise un XPath pendant qu'il manque une édition.
Les trois qui se lisent avant d'exécuter
Trois motifs dans le fichier suffisent à trancher : xsl:import-schema, xsl:stream ou
streamable="yes", et un appel de fonction dans un espace de noms qui désigne une classe Java. Leur
présence est une réponse ; leur absence en est une aussi.
Error: Requires a schema-aware processor
🔴 C'est le message le plus honnête des quatre, parce qu'il nomme la cause. Les trois autres désignent un symptôme — une fonction introuvable, une instruction inconnue, une lenteur — et laissent chercher.
Le piège qui coûte une journée
⚠️ « Ça marche sur la machine de l'intégration. » La même feuille, le même document, un résultat différent : la classe d'exécution de cette machine porte une édition supérieure. Rien dans la feuille ne déclare l'édition qu'elle exige, et rien dans l'erreur ne dit que la machine voisine en a une autre.
🔴 L'édition se vérifie, elle ne se suppose pas. Saxon l'affiche au démarrage avec l'option de trace, et c'est la première chose à comparer entre deux machines qui ne se comportent pas pareil — avant les versions de Java, avant les chemins de classe.
Ce qui ne dépend pas de l'édition
✅ xsl:result-document, les modes, les paquets, les fonctions d'ordre supérieur, les expressions
régulières, les cartes et les tableaux : tout cela est dans HE. Les questions d'écriture de
plusieurs fichiers, en particulier, n'ont rien à voir avec l'édition — elles se règlent comme le
décrit sorties multiples : ce que Saxon exige vraiment.
⚠️ Les fonctions d'extension intégrées, enregistrées par l'API de l'application appelante,
fonctionnent en HE. Ce qui manque est l'appel réflexif — nommer une classe Java directement
depuis la feuille. La nuance décide de la migration : du code qui passe par l'API se transpose, une
feuille qui appelle java.lang.Math ne se transpose pas.
Quand le message n'est pas explicite, la démarche de lire une trace d'erreur Saxon sans la deviner s'applique telle quelle.
Ce que cet article ne couvre pas
- les tarifs et les conditions de licence, qui changent et qu'il faut lire à la source ;
- Saxon-JS et les portages hors JVM, dont les éditions ne se recoupent pas avec celles-ci ;
- le détail des performances : « plus lent sans octets compilés » n'est pas un chiffre, et le facteur dépend entièrement de la feuille.
Le chapitre transformer et exporter du manuel indique quelle édition est utilisée par défaut, et comment le vérifier depuis l'application.