CODEWITHSUNDEEP
xsltdocumentsaxon
mokko
mokko

Reputation: 186

saxon transform vs saxon.jar document() behave differently

I have a stylesheet with a document() function. It finds the external document when i run it with saxon's transform on .Net, but not when i run it using java -jar saxon...

Please tell me that is well documented behavior and where it is documented!

Thank you guys! first version fails other succeeds

EDIT:

<xsl:stylesheet version="2.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes" />
    <xsl:strip-space elements="*" />

     <xsl:template match="/">
         <root>
             <xsl:variable name="dict" select="document('file:../data/mpxvoc.xml')"/>
             <xsl:message>
                 <xsl:value-of select="doc-available('file:../data/mpxvoc.xml')"/>
                 <xsl:value-of select="$dict/*/*[1]"/>
             </xsl:message>
         </root>
     </xsl:template>
</xsl:stylesheet>

EDIT2: Yes, same version!

EDIT3: Beginning of -t output on .NET/transform

C:\Users\mauri\OneDrive\smbdata\EM\SM-Plains\20200806>transform -t -s:2-MPX\vfix.mpx -xsl:C:\Users\mauri\eclipse-workspace\Pipeline\xsl\dtest.xsl -o:o.xml
Saxon-HE 9.9.1.6N from Saxonica
.NET 4.0.30319.42000 on Microsoft Windows NT 6.2.9200.0
URIResolver.resolve href="file:/C:/Users/mauri/eclipse-workspace/Pipeline/xsl/dtest.xsl" base="null"
Stylesheet compilation time: 1.25987s (1259.87ms)
Processing file:/C:/Users/mauri/OneDrive/smbdata/EM/SM-Plains/20200806/2-MPX/vfix.mpx
Using parser org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
Building tree for file:///C:/Users/mauri/OneDrive/smbdata/EM/SM-Plains/20200806/2-MPX/vfix.mpx using class net.sf.saxon.tree.tiny.TinyBuilder
Tree built in 222.8786ms
Tree size: 42580 nodes, 902487 characters, 26182 attributes
Building tree for file:///C:/Users/mauri/eclipse-workspace/Pipeline/data/mpxvoc.xml using class net.sf.saxon.tree.tiny.TinyBuilder
Tree built in 59.3813ms
Tree size: 20788 nodes, 725994 characters, 10214 attributes

...

Java version:

C:\Users\mauri\OneDrive\smbdata\EM\SM-Plains\20200806>java -jar "C:\Program Files\Saxonica\SaxonHE10-2J\saxon-he-10.2.jar" -t -s:2-MPX\vfix.mpx -xsl:C:\Users\mauri\eclipse-workspace\Pipeline\xsl\dtest.xsl -o:o.xml
Saxon-HE 10.2J from Saxonica
Java version 1.8.0_261
Stylesheet compilation time: 635.9066ms
Processing file:/C:/Users/mauri/OneDrive/smbdata/EM/SM-Plains/20200806/2-MPX/vfix.mpx
Using parser com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser
Building tree for file:/C:/Users/mauri/OneDrive/smbdata/EM/SM-Plains/20200806/2-MPX/vfix.mpx using class net.sf.saxon.tree.tiny.TinyBuilder
Tree built in 348.0487ms
Tree size: 42580 nodes, 902487 characters, 26182 attributes
URIResolver.resolve href="file:../data/mpxvoc.xml" base="file:/C:/Users/mauri/eclipse-workspace/Pipeline/xsl/dtest.xsl"
falseError FODC0002 while evaluating xsl:message at line 12 of file:/C:/Users/mauri/eclipse-workspace/Pipeline/xsl/dtest.xsl: Document has been marked not available: file:../data/mpxvoc.xml
Execution time: 414.5074ms
Memory used: 62Mb

URIResolver shows different bases. Is that it and is there a quick fix to get the same result in java?

Upvotes: 0

Views: 243

Answers (1)

Michael Kay
Michael Kay

Reputation: 163488

The URI file:../data/mpxvoc.xml is not a valid URI acccording to RFC 8089. Saxon however takes a liberal approach to URIs, in this context it passes the URI to the XML parser "as is", and if the parser is prepared to accept it then that's fine. At this point differences between platforms may well appear.

The solution is to avoid using URIs that don't conform to the standards. If you want a relative URI resolved against the base URI of the stylesheet, then drop the "file:" part.

RFC 8089 was only published in 2017, and until then the specs for the file URI scheme were hopelessly vague. The 2017 spec was far too late to make a real difference, since by then existing platforms like Java and .NET had to maintain compatibility with their respective past decisions. But if you stick to RFC 8089, you should be able to achieve reasonable portability.

Upvotes: 4

Related Questions