Saxon

Houston, we have a problem, fn:transform has gone missing for xsl:evaluate.

Simpler test case (run with 12.3 -it):

<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xsl:output method="text" omit-xml-declaration="yes" indent="yes"/>
  
  <xsl:param name="xpath" as="xs:string" expand-text="no"><![CDATA[
  transform(
    map {
      "delivery-format" : "raw",
      "stylesheet-text" : "<xsl:stylesheet xmlns:xsl=""http://www.w3.org/1999/XSL/Transform"" version=""3.0""><xsl:mode on-no-match=""shallow-copy""/></xsl:stylesheet>",
      "source-node": parse-xml('<root>test</root>')
    }
  )  
  ]]></xsl:param>
  
  <xsl:variable name="vResult" as="map(*)">
    <xsl:evaluate xpath="$xpath"/>
  </xsl:variable>
  
  <xsl:template name="xsl:initial-template">
    <xsl:sequence select=
      "serialize($vResult, map{'method':'adaptive'})"/>
  </xsl:template>
  
</xsl:stylesheet>

gives

Error in expression in xsl:evaluate/@xpath on line 16 column 35 of sheet1.xsl:
  XTDE3160  Static error in XPath expression supplied to xsl:evaluate: Cannot find a
  1-argument function named Q{http://www.w3.org/2005/xpath-functions}transform(). Expression: {
  transform(
    map {
      "delivery-format" : "raw",
      "stylesheet-text" : "<xsl:stylesheet
  xmlns:xsl=""http://www.w3.org/1999/XSL/Transform"" version=""3.0""><xsl:mode
  on-no-match=""shallow-copy""/></xsl:stylesheet>",
      "source-node": parse-xml('<root>test</root>')
    }
  )
  }
at template xsl:initial-template on line 19 column 45 of sheet1.xsl:
Static error in XPath expression supplied to xsl:evaluate: Cannot find a 1-argument function named Q{http://www.w3.org/2005/xpath-functions}transform(). Expression: {
  transform(
    map {
      "delivery-format" : "raw",
      "stylesheet-text" : "<xsl:stylesheet xmlns:xsl=""http://www.w3.org/1999/XSL/Transform"" version=""3.0""><xsl:mode on-no-match=""shallow-copy""/></xsl:stylesheet>",
      "source-node": parse-xml('<root>test</root>')
    }
  )
  }

This seems to be a bug since 12.0; basically, as far as I understand it, both 12 and 11 (tested with 12.3 and 11.6) in e.g. https://saxonica.plan.io/projects/saxonmirrorhe/repository/he/revisions/he_mirror_saxon_12_3/entry/src/main/java/net/sf/saxon/expr/instruct/EvaluateInstr.java#L525 and https://saxonica.plan.io/projects/saxonmirrorhe/repository/he/entry/src/main/java/net/sf/saxon/expr/instruct/EvaluateInstr.java?utf8=%E2%9C%93&rev=he_mirror_saxon_11_6#L356, respectively, do int version = instr.getRetainedStaticContext().getPackageData().getHostLanguageVersion(); but then while 11.6 in https://saxonica.plan.io/projects/saxonmirrorhe/repository/he/entry/src/main/java/net/sf/saxon/expr/instruct/EvaluateInstr.java?utf8=%E2%9C%93&rev=he_mirror_saxon_11_6#L380 does libraryList1.addFunctionLibrary(version == 40 ? XPath40FunctionSet.getInstance() : XPath31FunctionSet.getInstance()); Saxon 12.3 in https://saxonica.plan.io/projects/saxonmirrorhe/repository/he/revisions/he_mirror_saxon_12_3/entry/src/main/java/net/sf/saxon/expr/instruct/EvaluateInstr.java#L549 does libraryList1.addFunctionLibrary(config.getXPathFunctionSet(version)); and that way seems to pull the XPath 3.0 (not XPath 3.1) function library which doesn't have fn:transform.

xsl:evaluate is using the version of XPath that corresponds to the version of XSLT being used, which means that if XSLT 3.0 is used, you get XPath 3.0, which does not recognise the fn:transform() function.

Although XSLT 3.0 only mandates XPath 3.0 support, it permits processors to support XPath 3.1 and Saxon normally does so. The code change here was presumably intended to ensure that if XSLT 4.0 is in use, xsl:evaluate will support XPath 4.0, but the change had this unfortunate consequence.

In fact support for XPath 3.0 as distinct from 3.1 is largely discontinued in Saxon, and there are only a few vestiges left, such as the different function sets in the core function library.

Michael Kay wrote in #note-3:

xsl:evaluate is using the version of XPath that corresponds to the version of XSLT being used, which means that if XSLT 3.0 is used, you get XPath 3.0, which does not recognise the fn:transform() function.

Although XSLT 3.0 only mandates XPath 3.0 support, it permits processors to support XPath 3.1 and Saxon normally does so. The code change here was presumably intended to ensure that if XSLT 4.0 is in use, xsl:evaluate will support XPath 4.0, but the change had this unfortunate consequence.

In fact support for XPath 3.0 as distinct from 3.1 is largely discontinued in Saxon, and there are only a few vestiges left, such as the different function sets in the core function library.

Then let us immediately publish an official XSLT 3.1 Specification, containing the only sentence: " Same as 3.0 but mandating the support of XPath 3.1 "

Then let us immediately publish an official XSLT 3.1 Specification, containing the only sentence: " Same as 3.0 but mandating the support of XPath 3.1 "

A one-sentence change to the spec that would require a significant amount of effort in the test suite.

The way we set the XPath language level for xsl:evaluate is

env.setXPathLanguageLevel(version == 40 ? 40 : config.getConfigurationProperty(Feature.XPATH_VERSION_FOR_XSLT));

and we should use the same logic for the function library level. The property XPATH_VERSION_FOR_XSLT defaults to 31 but is configurable,

I have been adding to the unit tests in TestXsltCompiler to include testing of the language accepted by xsl:evaluate.

In doing this, I've established that for XPath expressions directly embedded in XSLT 3.0 we always (unconditionally) allow all functions defined in F+O 3.1, regardless of the configuration property XPATH_VERSION_FOR_XSLT (the configuration property only affects the XPath syntax accepted, not the function library). I don't intend to change this, because making functions unavailable that were previously available seems highly unfriendly.

Should the same apply to XPath expressions passed to xsl:evaluate? Well, ideally, xsl:evaluate would have a parameter to say which version of XPath is to be used. There's no particular reason it should be tied to the XSLT version, except as a default. The whole point is that the XPath expressions being evaluated are not actually part of the XSLT stylesheet code. But we're not designing new features here, we're fixing bugs...

I think I will make xsl:evaluate follow the same rules as directly embedded expressions - that is, you get the 3.1 function library unless you explicitly request 4.0.