Project

Profile

Help

Support #4752

closed

Undocumented change of IO failure handling when using document() between Saxon 9 and 10

Added by Jarno Elovirta over 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
JAXP Java API
Sprint/Milestone:
-
Start date:
2020-09-25
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
Platforms:

Description

I have a test project with Saxon 9.9 and Saxon 10 running side by side with (dummy testing) XSLT:

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:variable name="doc" select="document(resolve-uri('missing.xml', base-uri(/)))"/>
    <name>
      <xsl:value-of select="name($doc/*)"/>
    </name>
  </xsl:template>
</xsl:stylesheet>

When I run this in a test

final Configuration config = new Configuration();
final Processor processor = new Processor(config);
final XsltCompiler xsltCompiler = processor.newXsltCompiler();
final XsltExecutable xsltExecutable = xsltCompiler.compile(new StreamSource(this.getClass().getResource("test.xsl").toString()));
final XsltTransformer xsltTransformer = xsltExecutable.load();
xsltTransformer.setSource(new StreamSource(this.getClass().getResource("test.xsl").toString()));
xsltTransformer.setDestination(processor.newSerializer(System.out));
xsltTransformer.transform();

With Saxon 9.9.1-7 everything is as expected. The transformation completes and I get an error message

Warning at char 21 in xsl:variable/@select on line 3 column 90 of test.xsl:
  FODC0002: I/O error reported by XML parser processing
  file:/Users/jelovirt/Download/saxon-document/saxon-9/build/resources/test/missing.xml:
  /Users/jelovirt/Download/saxon-document/saxon-9/build/resources/test/missing.xml (No such
  file or directory)

However with Saxon 10.2 the transformation has a fatal error and throws and exception

Error at char 21 in expression in xsl:variable/@select on line 3 column 90 of test.xsl:
  FODC0002  I/O error reported by XML parser processing
  file:/Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml:
  /Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml (No such
  file or directory). Caused by java.io.FileNotFoundException:
  /Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml (No such
  file or directory)
  In template rule with match="/" on line 2 of test.xsl

I/O error reported by XML parser processing file:/Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml: /Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml (No such file or directory)
net.sf.saxon.s9api.SaxonApiException: I/O error reported by XML parser processing file:/Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml: /Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml (No such file or directory)
	at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:361)
	at DocumentTest.testSaxon10Document(DocumentTest.java:18)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
	at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
	at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
	at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
	at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
	at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: net.sf.saxon.trans.XPathException: I/O error reported by XML parser processing file:/Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml: /Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml (No such file or directory)
	at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:467)
	at net.sf.saxon.event.Sender.send(Sender.java:142)
	at net.sf.saxon.functions.DocumentFn.makeDoc(DocumentFn.java:299)
	at net.sf.saxon.functions.DocumentFn$DocumentMappingFunction.mapItem(DocumentFn.java:148)
	at net.sf.saxon.expr.ItemMappingIterator.next(ItemMappingIterator.java:117)
	at net.sf.saxon.om.SequenceIterator.forEachOrFail(SequenceIterator.java:135)
	at net.sf.saxon.expr.sort.DocumentOrderIterator.<init>(DocumentOrderIterator.java:49)
	at net.sf.saxon.functions.DocumentFn.call(DocumentFn.java:119)
	at net.sf.saxon.expr.FunctionCall.iterate(FunctionCall.java:548)
	at net.sf.saxon.expr.Expression.evaluateItem(Expression.java:852)
	at net.sf.saxon.expr.SimpleStepExpression.iterate(SimpleStepExpression.java:121)
	at net.sf.saxon.expr.CardinalityChecker.evaluateItem(CardinalityChecker.java:283)
	at net.sf.saxon.expr.parser.Evaluator$6.evaluate(Evaluator.java:173)
	at net.sf.saxon.expr.SystemFunctionCall.evaluateArguments(SystemFunctionCall.java:454)
	at net.sf.saxon.expr.FunctionCall.iterate(FunctionCall.java:546)
	at net.sf.saxon.expr.Expression.process(Expression.java:949)
	at net.sf.saxon.expr.SystemFunctionCall.process(SystemFunctionCall.java:481)
	at net.sf.saxon.expr.instruct.ValueOf.processLeavingTail(ValueOf.java:340)
	at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:142)
	at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:352)
	at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:298)
	at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:384)
	at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:568)
	at net.sf.saxon.trans.XsltController.applyTemplates(XsltController.java:661)
	at net.sf.saxon.s9api.AbstractXsltTransformer.applyTemplatesToSource(AbstractXsltTransformer.java:360)
	at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:349)
	... 48 more
Caused by: java.io.FileNotFoundException: /Users/jelovirt/Download/saxon-document/saxon-10/build/resources/test/missing.xml (No such file or directory)
	at java.base/java.io.FileInputStream.open0(Native Method)
	at java.base/java.io.FileInputStream.open(FileInputStream.java:212)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:154)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:109)
	at java.base/sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:86)
	at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:184)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:652)
	at java.xml/com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:150)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:860)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
	at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1224)
	at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
	at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:439)
	... 73 more

Reading the 9.9 -> 10 change history, I can't find anything that documents this change and how to configure Saxon to retain the old just-log-error behaviour.

Actions #1

Updated by Michael Kay over 3 years ago

Thanks for pointing this out. I think it's a consequence of moving gradually over to the XSLT 3.0 model, which no longer has a concept of "recoverable errors" and instead relies on try/catch for failure handling. The 3.0 spec does give processors the option of ignoring a failure from the document() function, and that's probably the last vestige of the "recoverable error" concept in earlier releases of the spec, but it seems a poor choice when try/catch is available to explicitly catch the error. Perhaps we need a configuration option to reinstate the earlier behaviour.

Actions #2

Updated by Michael Kay over 3 years ago

Also, of course, XSLT 2.0 introduced doc-available() to help you manage this situation. And if you don't want to make changes to the XSLT code, you could handle it in a custom URIResolver. So with a variety of techniques already available, I'm a bit reluctant to add yet another. If we did, perhaps the right approach would be to reinstate the Configuration option RECOVERY_POLICY which was used to control this (and other "recoverable errors", including most notably template rule ambiguities) in the past.

Actions #3

Updated by Jarno Elovirta over 3 years ago

This is a case where we'd like to update Saxon in DITA-OT, but we don't control the XSLT plug-ins to DITA-OT use. So we can't force users to use doc-available(). Maybe we then just have to wait until out next major release and move to XSLT 3.0 and Saxon 10 as the same time. But it's a high cost because users will not migrate because old XSLT 2.0 based plug-ins no longer work.

Actions #4

Updated by Jarno Elovirta over 3 years ago

And if you don't want to make changes to the XSLT code, you could handle it in a custom URIResolver.

How do you see this would work. I already have custom URIResolvers in place, so this would be easy to implement. But which Source could I return that Saxon would use and get an empty document node? If I return an XdmNode that is a document node and has no childrent, it would still be a non-empty node sequence.

Actions #5

Updated by Michael Kay over 3 years ago

  • Category set to JAXP Java API
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

I decided to add an implementation of Source, namely net.sf.saxon.lib.EmptySource, which a URIResolver can return to indicate that the document request should be silently ignored. For doc() and document() the effect is that the function returns an empty sequence; for xsl:source-document the effect is that the instruction does nothing; for xsl:include/import the effect is to load a dummy stylesheet module containing just an empty xsl:transform instruction.

Actions #6

Updated by Michael Kay over 3 years ago

  • Status changed from New to Resolved
  • Applies to branch 10, trunk added
  • Fix Committed on Branch 10, trunk added
Actions #7

Updated by O'Neil Delpratt about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 10.5 added

Bug fix applied to Saxon 10.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF