Reference: Saxon XSLT Processor Changes

The following table summarizes Workday support for various versions of Saxon and XSLT. Note that after version 27, Workday introduced a new naming scheme in the form

year.week

Workday Version	Supported Saxon Version	Supported XSLT Version	Notes
<20	9.1	1.0, (2.0)	Limited support for XSLT version 2.0.
20-2017.05	9.4	2.0, (3.0)	Limited support for XSLT version 3.0.
2017.05-	9.7	3.0	Support for XSLT streaming.

Studio displays a warning message if you create a collection containing assemblies with different version numbers. This is because differently versioned assemblies can require conflicting versions of Saxon, leading to class loading errors at runtime. Best practice is to use the latest assembly versions for all of your integrations.

Note the following:

The XPath methods that are available in MVEL for accessing message parts and variables support XPath 3.0.

The

mctx

URL protocol allows XSL developers to write to message parts and variables, for example:

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

Although there is no direct assembly support for XQuery, you can add custom steps to call XQuery scripts.

In assemblies versioned 2022.46 or earlier, Saxon is set as the default transformer only when the

use.saxon.transformer

property is set to

true

in the mediation context. In assemblies versioned 2022.47 or later, Saxon is set as the default if that property is set to

true

or if it's not present.

XSLT 2.0 and XSLT 3.0 are strongly typed. For example, they do not allow

xs:string

to be evaluated for equality in XPath expressions. The following expression, in which

stringParam

is an XSL parameter, results in a Saxon runtime error:

$stringParam = true()

The XSL compiler will not encounter the issue at deploy time, because it cannot predict what type the parameter will have in advance.

Your existing XSL documents and Workday Studio integrations will not be impacted by this strong typing issue, unless you choose to enable XSLT 3.0 by changing the

version

attribute value in your XSL documents to

3.0

. If you encounter these runtime errors, which result from the XSLT that you deploy with your integration, you must take action to fix them.

The following error relating to the Saxon upgrade has been observed in legacy XSL for business forms printing:

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

If you encounter this error, check whether your XSL contains the following attribute setting on a sort element:

case-order="#default"

This optional

case-order

attribute determines whether the sort lists upper or lower case letters first in the sort. The default is to list upper case first. The Saxon parser accepts only these values for case-order:

upper-first

lower-first

To fix this error, do one of the following:

Remove the existing case-order attribute from the sort element, because it is an optional setting.

Set the case-order value explicitly to

upper-first

Set the case-order value explicitly to

lower-first