Project

Profile

Help

Bug #5378

closed

The system identifier of the principal output file is unknown

Added by O'Neil Delpratt 9 months ago. Updated 9 months ago.

Status:
Rejected
Priority:
Normal
Category:
Saxon-C Internals
Start date:
2022-03-08
Due date:
% Done:

0%

Estimated time:
Found in version:
11.2
Fixed in version:
Platforms:

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

Related to SaxonC - Bug #5376: Saxon EE 11.2 "TransformToString()" produces JET RUNTIME with an exit code of 9AwaitingInfoO'Neil Delpratt2022-03-08

Actions
Actions #1

Updated by O'Neil Delpratt 9 months ago

  • Related to Bug #5376: Saxon EE 11.2 "TransformToString()" produces JET RUNTIME with an exit code of 9 added
Actions #2

Updated by Martin Honnen 9 months 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.

Actions #3

Updated by Michael Kay 9 months 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.

Actions #4

Updated by Martin Honnen 9 months 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.

Actions #5

Updated by O'Neil Delpratt 9 months ago

  • Status changed from New to Rejected

Closing this bug issue as no further action needed.

Please register to edit this issue

Also available in: Atom PDF