Passer au contenu principal
Documentation
Documentation
Administrator Guide
Dernière mise à jour : 2023-06-23
Référence : changements liés au processeur XSLT Saxon

Référence : changements liés au processeur XSLT Saxon

Le tableau suivant récapitule le soutien de Workday pour les différentes versions de axe et de XSLT. Notez qu'après la version 27, Workday a apporté un nouveau schéma de dénomination dans le formulaire
year.week
.
Version de Workday
Version Saxon prise en charge
Version 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,0
Prise en charge du flux XSLT.
Studio affiche un message d’avertissement si vous créez une collection contenant des assemblages avec des numéros de version différents. En effet, des assemblages de versions différentes peuvent nécessiter des versions contradictoires de Saxon, ce qui entraîne des erreurs de chargement des classes au moment de l’exécution. La meilleure pratique consiste à utiliser les dernières versions d’assemblage pour toutes vos intégrations.
Tenez compte des éléments suivants :
  • Les méthodes XPath qui sont disponibles dans MVEL pour l’accès aux parties et aux variables des messages prennent en charge XPath 3.0.
  • La
    mctx
     Le protocole URL permet aux développeurs XSL d’écrire des parties de messages et des variables, par exemple : 
    <xsl:result-document href="mctx:vars/var1">...</xsl:result-document>
  • Bien qu’il n’y ait pas de prise en charge de l’agrégation directe pour XQuery, vous pouvez ajouter des étapes personnalisées pour appeler les scripts XQuery.
  • Dans les agrégats dont la version est identique ou antérieure à la version 2022.46, axe.
    use.saxon.transformer
     propriété est définie comme suit
    true
     dans le contexte de la médiatisation. Dans les agrégats dont la version est identique ou postérieure à la version 2022.47, axe est défini comme valeur par défaut si cette propriété est définie à
    true
     ou si elle n'est pas présente.
XSLT 2.0 et XSLT 3.0 sont fortement marqués. Par exemple, ils n'autorisent pas
xs:string
 à évaluer l'égalité dans les expressions XPath. L'expression suivante, dans laquelle
stringParam
 est un paramètre XSL, entraîne une erreur d'exécution axe :. 
$stringParam = true()
Le compilateur XSL ne détectera pas le problème au moment du déploiement, car il ne peut pas prédire le type du paramètre à l'avance.
Ce problème de saisie n'aura pas d'incidence sur vos documents XSL et vos intégrations Workday Studio, à moins que vous choisissiez d'activer XSL 3.0 en changeant la valeur de l'attribut de
version
 dans vos documents XSL pour la remplacer par
3.0
. Si vous rencontrez ces erreurs d’exécution, qui résultent de XSLT que vous déployez avec votre intégration, vous devez prendre des mesures pour les corriger.
L'erreur suivante, relative à la mise à niveau de l'axe correspondante, a été repérée dans l'ancien XSL pour l'impression des formulaires commerciaux : 
Failed to compile stylesheet.
X
errors detected. Invalid value for @case-order. Value must be one of (lower-first|upper-first).
Si vous rencontrez cette erreur, vérifiez si votre XSL contient le paramètre d’attribut suivant dans un élément de tri : 
case-order="#default"
Ceci est facultatif
case-order
 L'attribut de tri détermine si les lettres en majuscules ou en minuscules sont premières dans le tri. La valeur par défaut consiste à présenter d'abord les majuscules. L’analyseur saxon accepte uniquement les valeurs suivantes pour l’ordre des cas :
  • upper-first
  • lower-first
Pour corriger cette erreur, effectuez l'une des actions suivantes :
  • Retirez l'attribut case-order existant de l'élément de tri , car il s'agit d'un paramètre facultatif.
  • Définissez la valeur d'ordre des cas sur
    upper-first
    .
  • Définissez la valeur d'ordre des cas sur
    lower-first
    .