Saxon

My findings so far:

(a) It works under Saxon-EE, even when running without a license file

(b) Both under Saxon-HE 10.0 and 10.1 it fails in a different way from that reported:

java.lang.NullPointerException
	at net.sf.saxon.s9api.Xslt30Transformer.transform(Xslt30Transformer.java:379)
	at net.sf.saxon.functions.TransformFn.call(TransformFn.java:802)
	at net.sf.saxon.expr.FunctionCall.iterate(FunctionCall.java:543)
	at net.sf.saxon.expr.Expression.evaluateItem(Expression.java:852)
	at net.sf.saxon.expr.LookupExpression.iterate(LookupExpression.java:316)
	at net.sf.saxon.expr.parser.Evaluator$7.evaluate(Evaluator.java:199)
	at net.sf.saxon.expr.SystemFunctionCall.evaluateArguments(SystemFunctionCall.java:449)
	at net.sf.saxon.expr.FunctionCall.iterate(FunctionCall.java:541)

Line 379 is in fact on an error path where it is trying to call the ErrorListener; it's presumably failing because we don't have an ErrorListener, we have an ErrorReporter. To find out what the primary error is (the one it's trying to report) I'll need to build an HE-only project for debugging.

Can my result of the failure with EE be caused by my particular license which is not a full EE license but EE-T? But the stylesheet does nothing but

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">

<xsl:mode on-no-match="shallow-copy" streamable="yes"/>

<xsl:template match="/*">
  <xsl:next-match/>
  <xsl:comment select="'Processed at', current-dateTime(), 'with xsl:supports-streaming', system-property('xsl:supports-streaming')"/>
</xsl:template>

</xsl:stylesheet>

still not sure at what point the XQuery or XSLT creates "a schema-validated source document".

Yes, it could be that the EE-T license is an issue.

The problem is probably xs:untyped vs xs:anyType. If there's a node annotated xs:anyType that counts as a "schema-validated node" for the purpose of this error message. If XSLT can handle typed nodes (as it can with an EE-T license) then under appropriate conditions it can generate xs:anyType rather than xs:untyped, and if XQuery is non-schema-aware (as it is with an EE-T license) then it will reject xs:anyType. I think with this kind of license there are probably going to be interoperability issues passing data from XSLT to XQuery or vice versa.

Shallow-copy implicitly uses validation=preserve, which despite its name gives shallow-copied nodes a type of xs:anyType (that's because the content of the element might contain typed nodes, which would be invalid for xs:untyped). So nodes passed to the query will be annotated xs:anyType and the non-schema-aware XQuery isn't prepared to handle that.

In principle it would be better if non-schema-aware code ignored type annotations rather than rejecting them. But it would be hard to implement that reliably.

Can you work around it by using a default template rule with <xsl:copy validation="strip">?

Michael Kay wrote:

Yes, it could be that the EE-T license is an issue.

The problem is probably xs:untyped vs xs:anyType. If there's a node annotated xs:anyType that counts as a "schema-validated node" for the purpose of this error message. If XSLT can handle typed nodes (as it can with an EE-T license) then under appropriate conditions it can generate xs:anyType rather than xs:untyped, and if XQuery is non-schema-aware (as it is with an EE-T license) then it will reject xs:anyType. I think with this kind of license there are probably going to be interoperability issues passing data from XSLT to XQuery or vice versa.

Shallow-copy implicitly uses validation=preserve, which despite its name gives shallow-copied nodes a type of xs:anyType (that's because the content of the element might contain typed nodes, which would be invalid for xs:untyped). So nodes passed to the query will be annotated xs:anyType and the non-schema-aware XQuery isn't prepared to handle that.

In principle it would be better if non-schema-aware code ignored type annotations rather than rejecting them. But it would be hard to implement that reliably.

Can you work around it by using a default template rule with <xsl:copy validation="strip">?

Yes, using <xsl:copy validation="strip"> instead of relying on xsl:mode on-no-match="shallow-copy" fixes the problem and now that I have understood the reasons I will be able to apply that.

Bug fix applied in the Saxon 10.3 maintenance release