Referentie: Saksische XSLT-processorwijzigingen

In de volgende tabel vindt u een overzicht van Workday-ondersteuning voor verschillende versies van Saxon en XSLT. Houd er rekening mee dat Workday na versie 27 een nieuw naamgevingsschema in het formulier heeft geïntroduceerd

year.week

Workday-versie	Ondersteunde Saksische versie	Ondersteunde XSLT-versie:	Opmerkingen
<20	9.1	1.0, (2.0)	Beperkte ondersteuning voor XSLT-versie 2.0.
20-2017.05	9.4	2.0, (3.0)	Beperkte ondersteuning voor XSLT-versie 3.0.
2017.05-	9.7	3.0	Ondersteuning voor XSLT-streaming.

Studio geeft een waarschuwingsbericht weer als u een verzameling maakt die merken met verschillende versienummers bevat. Dit komt omdat voor assemblies met verschillende versies mogelijk conflicterende versies van Saxon zijn vereist, wat kan leiden tot fouten bij het laden van de klasse tijdens runtime. Best practice is om de nieuwste assembly-versies te gebruiken voor al uw integraties.

Houd rekening met het volgende:

De XPath-methoden die beschikbaar zijn in MVEL voor toegang tot berichtonderdelen en -variabelen ondersteunen XPath 3.0.

mctx

Met het URL-protocol kunnen XSL-ontwikkelaars schrijven naar berichtonderdelen en -variabelen, bijvoorbeeld:

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

Hoewel er geen ondersteuning voor directe assembly is voor XQuery, kunt u aangepaste stappen toevoegen om XQuery-scripts aan te roepen.

In assemblies met versie 2022.46 of eerder wordt Saxon alleen ingesteld als de standaardtransformatie wanneer de

use.saxon.transformer

eigenschap is ingesteld op

true

in de bemiddelingscontext. In assemblies met versie 2022.47 of hoger wordt Saxon als standaard ingesteld als die eigenschap is ingesteld op:

true

of als deze niet aanwezig is.

XSLT 2.0 en XSLT 3.0 zijn sterk getypeerd. Ze staan bijvoorbeeld niet toe:

xs:string

moet worden geëvalueerd op gelijkheid in XPath-expressies. De volgende expressie, waarin

stringParam

is een XSL-parameter, resulteert in een Saksische runtimefout:

$stringParam = true()

De XSL-compiler zal het probleem niet tegenkomen tijdens de implementatie, omdat niet van tevoren kan worden voorspeld welk type de parameter zal hebben.

Uw bestaande XSL-documenten en Workday Studio-integraties worden niet beïnvloed door dit typefout, tenzij u ervoor kiest XSLT 3.0 in te schakelen door de

versiekenmerkwaarde

in uw XSL-documenten te wijzigen in

3.0

. Als u deze runtimefouten tegenkomt, die het gevolg zijn van de XSLT die u implementeert met uw integratie, moet u actie ondernemen om ze te corrigeren.

De volgende fout met betrekking tot de Saksische upgrade is gevonden in verouderde XSL voor het afdrukken van zakelijke formulieren:

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

Als deze fout zich voordoet, controleert u of uw XSL de volgende kenmerkinstelling voor een sorteerelement bevat:

case-order="#default"

Deze optionele

case-order

Het kenmerk bepaalt of hoofdletters of kleine letters als eerste in de sortering worden weergegeven. Standaard worden hoofdletters als eerste weergegeven. De Saksische parser accepteert alleen de volgende waarden voor de hoofdlettervolgorde:

upper-first

lower-first

Voer een van de volgende handelingen uit om deze fout te corrigeren:

Verwijder het bestaande kenmerk case-order uit het sorteerelement, omdat dit een optionele instelling is.

Stel de casevolgordewaarde expliciet in op:

upper-first

Stel de casevolgordewaarde expliciet in op:

lower-first