Référence : modifications du processeur XSLT Saxon

Le tableau suivant récapitule la prise en charge par Workday des différentes versions de Saxon et de XSLT. Notez qu'après la version 27, Workday a introduit un nouveau système de dénomination dans le formulaire

year.week

Version Workday	Version de Saxon prise en charge	Version de XSLT prise en charge	Remarques
<20	9.1	1.0, (2.0)	Prise en charge limitée de XSLT version 2.0.
20-2017.05	9.4	2.0, (3.0)	Prise en charge limitée de XSLT version 3.0.
2017.05-	9.7	3	Prise en charge du streaming XSLT.

Workday Studio affiche un message d'avertissement si vous créez une collection contenant des assemblages avec des numéros de version différents. Cela est dû au fait que les assemblages versionnés différemment peuvent nécessiter des versions de Saxon en conflit, ce qui entraîne des erreurs de chargement des classes lors de l'exécution. Il est recommandé d'utiliser les dernières versions d'assemblage pour toutes vos intégrations.

Notez les éléments suivants :

Les méthodes XPath disponibles dans MVEL pour accéder aux parties de message et aux variables prennent en charge XPath 3.0.

mctx

Le protocole URL permet aux développeurs XSL d'écrire des parties et des variables de message, par exemple :

<xsl:result-document href="mctx:vars/var1">...</xsl:result-document>

Bien qu'il n'y ait pas de prise en charge directe des assemblages pour XQuery, vous pouvez ajouter des étapes personnalisées pour appeler des scripts XQuery.

Dans les agrégats versionnés 2022.46 ou antérieures, SON est défini comme Transformateur par défaut uniquement lorsque :

use.saxon.transformer

propriété est définie sur

true

dans le contexte de la médiatisation. Dans les agrégats versionnés 2022.47 ou ultérieures, SON est défini comme valeur par défaut si cette propriété est définie sur

true

ou si ce n'est pas le cas.

XSLT 2.0 et XSLT 3.0 sont fortement typés. Par exemple, ils n'autorisent pas

xs:string

afin d'évaluer l'égalité dans les expressions XPath. L'expression suivante, dans laquelle

stringParam

est un paramètre XSL, cela donne une erreur d'exécution axe :

$stringParam = true()

Le compilateur XSL ne rencontrera pas ce problème au moment du déploiement, car il ne peut pas prédire à l'avance le type du paramètre.

Vos documents XSL existants et vos intégrations Workday Studio ne seront pas impactés par ce problème de saisie fort, sauf si vous choisissez d'activer XSLT 3.0 en modifiant la valeur d'attribut de

version

de vos documents XSL par.

3.0

. Si vous rencontrez ces erreurs d'exécution, dues au XSLT que vous déployez avec votre intégration, vous devez les corriger.

L'erreur suivante liée à la mise à niveau vers le saxon a été constatée dans l'ancien fichier XSL pour l'impression des formulaires :

Failed to compile stylesheet.Xerrors detected. Invalid value for @case-order. Value must be one of (lower-first|upper-first).

Si vous rencontrez cette erreur, vérifiez que votre fichier XSL contient le paramètre d'attribut suivant sur un élément de tri :

case-order="#default"

Cette option

case-order

L'attribut détermine si le tri répertorie en premier les lettres en majuscules ou en minuscules. Par défaut, les majuscules sont affichées en premier. L'analyseur Saxon accepte uniquement les valeurs suivantes pour case-order :

upper-first

lower-first

Pour corriger cette erreur, effectuez l'une des actions suivantes :

Supprimez l'attribut case-order existant de l'élément de tri, car il s'agit d'un paramètre facultatif.

Définissez la valeur de l'ordre de cas de manière explicite sur

upper-first

Définissez la valeur de l'ordre de cas de manière explicite sur

lower-first