Bug #4560
closed![Author: Michael Kay](https://www.gravatar.com/avatar/db6526d63053f09b62e52c2da8b2230a?rating=PG&size=50&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
![Assignee: Michael Kay](https://www.gravatar.com/avatar/db6526d63053f09b62e52c2da8b2230a?rating=PG&size=22&default=https%3A%2F%2Fassets.plan.io%2Fimages%2Fdefault_avatar.png)
Failure running fn:transform() from XQuery under Saxon-HE
100%
Description
Transferred from help forum, post #7895
When I run the XQuery code
transform(
map {
'initial-match-selection' :
transform(
map {
'source-location' : 'input1.xml',
'stylesheet-location' : 'sheet1.xsl',
'delivery-format' : 'raw'
}
)?output,
'stylesheet-location' : 'sheet1.xsl'
}
)?output
with some input XML and a not schema-aware stylesheet using Saxon-HE 10.1J with the command line java -cp saxon-he-10.1.jar net.sf.saxon.Query -t .\chain-two-xslts2.xq it succeeds while using Saxon-EE 10.1J with java -cp saxon-ee-10.1.jar net.sf.saxon.Query -t .\chain-two-xslts2.xq fails with an error "Cannot use a schema-validated source document unless the stylesheet is schema-aware".
Updated by Michael Kay over 4 years ago
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.
Updated by Martin Honnen over 4 years ago
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".
Updated by Michael Kay over 4 years ago
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">
?
Updated by Michael Kay over 4 years ago
- Fix Committed on Branch 10 added
As regards the NullPointerException
:
(a) there are three places in the code that AbstractXsltTransformer.getErrorListener()
is called. These should be changed to use the new getErrorReporter()
interface instead.
(b) The documentation for AbstractXsltTransformer.getErrorListener()
says that if no user-supplied error listener is available, a system-defined one will be returned. This isn't what the code is doing; it is returning null. We should change the code to match the documentation, by returning an ErrorListener
that wraps the ErrorReporter
.
I have applied these changes
Updated by Martin Honnen over 4 years ago
Michael Kay wrote:
Yes, it could be that the EE-T license is an issue.
The problem is probably
xs:untyped
vsxs:anyType
. If there's a node annotatedxs: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 generatexs:anyType
rather thanxs:untyped
, and if XQuery is non-schema-aware (as it is with an EE-T license) then it will rejectxs: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 forxs:untyped
). So nodes passed to the query will be annotatedxs: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.
Updated by Michael Kay almost 4 years ago
- Status changed from New to Resolved
I'm going to mark this resolved. The effect of the patch was to give an error message attempting to explain the situation, rather than crashing. I don't think it's easy to do much about the error (a non-schema-aware stylesheet doesn't accept schema-typed nodes as input); we could get better at explaining it in error messages or documentation, but I don't think it's going to be a common enough problem to justify the effort.
Updated by O'Neil Delpratt almost 4 years ago
Bug fix applied in the Saxon 10.3 maintenance release
Updated by O'Neil Delpratt almost 4 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 10.3 added
Please register to edit this issue