Bug #5378
closed
The system identifier of the principal output file is unknown
0%
Description
The following comment was raised by Martin in the bug issue #5376 :
It seems still a bit confusing that transformToString works fine without setting xslte->setBaseOutputURI("file:///location/"); in code not using xsl:result-document e.g. with
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0" expand-text="yes">
<xsl:output method="xml" encoding="utf-8" standalone="yes" indent="yes"/>
<xsl:template match="/">
<xsl:message>producing sheet</xsl:message>
<main-result>
<tested-at>{current-dateTime()}</tested-at>
<static-base-uri>{static-base-uri()}</static-base-uri>
</main-result>
<!--<xsl:result-document href="output.xml">
<result>
<value>
You put a <xsl:value-of select="/xml/value"/>
</value>
</result>
</xsl:result-document>-->
</xsl:template>
</xsl:stylesheet>
but as soon as I uncomment the use of xsl:result-document with the relative URI SaxonC gives the
SXRD0002 The system identifier of the principal output file is unknown
In template rule with match="/" on line 4 of result-document-test2.xsl
Perhaps that just needs better documentation/explanation in the documentation that the use of the transformToString together with xsl:result-document requires an explicit setting of the base output URI if relative URIs are used in the XSLT. But it kind of feels that the base output uri might be available from the stylesheet's base URI, as it seems to be if the target is a transformToFile.
Related issues
Updated by O'Neil Delpratt about 2 years ago
- Related to Bug #5376: Saxon EE 11.2 "TransformToString()" produces JET RUNTIME with an exit code of 9 added
Updated by Martin Honnen about 2 years ago
Thinking more from the XSLT side of things I now consider using e.g. <xsl:result-document href="{resolve-uri('output.xml', static-base-uri())}"> inside of the XSLT as an appropriate approach to make sure the relative result document's URI/file name is resolved against the static base URI/the used stylesheet's URI if the primary output is directed to a string with the API of C++ or PHP or Python. But I am open to a more flexible, user convenient default handling from inside Saxon or a better documentation of the need to set the base output URI for secondary, relative result URIs if the main transformation result is a string.
Updated by Michael Kay about 2 years ago
There's nothing more confusing (or potentially dangerous) than writing output files to a location where the user didn't expect them to be written. The XSLT spec says that relative URIs in xsl:result-document/@href are interpreted relative to the "base output URI", and while it's reasonable to default this to the location where the principal output goes, if you've explicitly asked for the principal output to be returned as a string, then I don't think we should be writing secondary outputs to file store unless we're given very explicit directions as to where they should go.
It could reasonably default to either the stylesheet location or the current working directory, but both run the risk of overwriting existing files and I think it's safer to require the user to supply an explicit location.
Updated by Martin Honnen about 2 years ago
I agree, Mike, I think my initial thinking is a bit flawed, the actual use case to rely on transformToString is only an attempt to avoid a bug in transformToFile anyway, I think, so once that fix is released the user can return to have a file output instead of a string and the whole issue doesn't arise.
Updated by O'Neil Delpratt about 2 years ago
- Status changed from New to Rejected
Closing this bug issue as no further action needed.
Please register to edit this issue
.