Bug #6146
closedrelative URI resolution in XQuery vs XSLT when loading (XQuery/XSLT) code from the command line over HTTP(S)
80%
Description
Using SaxonJ HE 12.3, I found that the net.sf.saxon.Transform
, when taking the -xsl
option as a HTTP(S) URL, resolves relative URIs in the XSLT code relative to the loaded XSLT stylesheet so e.g.
java -cp 'C:\Program Files\Saxonica\SaxonHE12-3J\saxon-he-12.3.jar' net.sf.saxon.Transform -t -it -xsl:https://martin-honnen.github.io/xquery/relative-uri-test1.xsl
gives me an output like
SaxonJ-HE 12.3 from Saxonica
Java version 11.0.19
Stylesheet compilation time: 1.9040145s (1904.0145ms)
Processing (no source document) initial template = xsl:initial-template
Building tree for https://martin-honnen.github.io/xquery/sample1.xml using class net.sf.saxon.tree.tiny.TinyBuilder
Tree built in 2.0469ms
Tree size: 4 nodes, 15 characters, 0 attributes
<?xml version="1.0" encoding="UTF-8"?>
<results>
<doc-test>
<root>This is a test.</root>
</doc-test>
<unparsed-text-test>This is a plain text test file.
</unparsed-text-test>
</results>
Now when I use a similar XQuery code, however, Saxon tries to resolve the relative URIs relative to the working directory for the unparsed-text
call while saying there is no base URI for doc
, it appears:
PS C:\Users\marti> java -cp 'C:\Program Files\Saxonica\SaxonHE12-3J\saxon-he-12.3.jar' net.sf.saxon.Query -t -q:https://martin-honnen.github.io/xquery/relative-uri-test1.xq
SaxonJ-HE 12.3 from Saxonica
Java version 11.0.19
Analyzing query from https://martin-honnen.github.io/xquery/relative-uri-test1.xq
Analysis time: 1765.7914 milliseconds
<?xml version="1.0" encoding="UTF-8"?>
<results>
<doc-test>Relative URI passed to document() function (sample1.xml); but no base URI is available</doc-test>
<unparsed-text-test>Cannot read file:/C:/Users/marti/sample1.txt(C:\Users\marti\sample1.txt (Das System kann die angegebene Datei nicht finden))</unparsed-text-test>
</results>
The documentation between calling XSLT and XQuery from the command line seems a bit different, for XSLT it seems to mention the option to load the XSLT as a URI (file or http), for XQuery it is not quite clear but it seems as if if code is loadable over HTTP(S) should then it also should have the base URI set.
Used online files: https://martin-honnen.github.io/xquery/relative-uri-test1.xq, https://martin-honnen.github.io/xquery/relative-uri-test1.xsl
Updated by Martin Honnen over 1 year ago
When I use my own Java code and set the base URI on the XQuery compiler with e.g.
String sampleQueryURI = "https://martin-honnen.github.io/xquery/relative-uri-test1.xq";
URL sampleQueryURL = new URL(sampleQueryURI);
Processor processor = new Processor();
XQueryCompiler xqueryCompiler = processor.newXQueryCompiler();
xqueryCompiler.setBaseURI(sampleQueryURL.toURI());
InputStream queryStream = sampleQueryURL.openStream();
XQueryExecutable xqueryExecutable = xqueryCompiler.compile(queryStream);
queryStream.close();
XQueryEvaluator xqueryEvaluator = xqueryExecutable.load();
xqueryEvaluator.run(processor.newSerializer(System.out));
I get the expected result, similar to the one Saxon gives from the command line when loading the respective XSLT code over HTTP(S).
Now the question is: is Saxon's command line for XQuery not supposed to run code provided as an HTTP(S) URI or has it a bug/quirk not setting the base URI on the compiler?
Updated by Michael Kay over 1 year ago
- Tracker changed from Support to Bug
- Status changed from New to In Progress
You are right (as always), it seems that Saxon is not setting the static base URI of the query on this path.
Updated by Michael Kay over 1 year ago
- Status changed from In Progress to Resolved
- Applies to branch 10, 11, 12, trunk added
- Fix Committed on Branch 10, 11, 12, trunk added
- Platforms .NET, Java added
Updated by Debbie Lockett over 1 year ago
- % Done changed from 0 to 50
- Fixed in Maintenance Release 11.6 added
Bug fix applied in the Saxon 11.6 maintenance release.
Updated by O'Neil Delpratt about 1 year ago
- Status changed from Resolved to Closed
- % Done changed from 50 to 100
- Fixed in Maintenance Release 12.4 added
Bug fix applied in the Saxon 12.4 Maintenance release
Updated by Debbie Lockett about 1 year ago
- Status changed from Closed to Resolved
- % Done changed from 100 to 80
Leave as "resolved" rather than "closed" as fix has not gone out in a Saxon 10 maintenance release.
Please register to edit this issue