xsl:result-document

Used to direct output to a secondary output destination.

Category: instruction
Content: sequence-constructor
Permitted parent elements: any XSLT element whose content model is sequence constructor; any literal result element

Attributes

format?

{ eqname }

If present, it gives the name of an xsl:output element that describes the serialization format for this output document; if absent, the unnamed xsl:output declaration is used.

href?

{ uri }

The URI for the result document. If this is a relative URI, it is interpreted relative to the base output URI. The base output URI is the systemID of the result object supplied as the destination for the transformation, or if you are using the command line, the value of the -o flag. If the href attribute is omitted, the document is written to the location identified by the base output URI: this will only work if all the output produced by the stylesheet is within the scope of an xsl:result-document instruction.

If the base output URI is not known, then the current directory is used, unless the configuration disables calling of extension functions, in which case it is assumed that the stylesheet is not trusted to overwrite files relative to the current directory, and an error is then reported.

This base output URI must be a writable location. Usually it will therefore be a URI that uses the "file:" scheme. However, Saxon attempts to open a connection whatever URI scheme is used, and it should therefore work with any URI where the Java VM has the capability to open a writable connection. Users have reported success in using "ftp:" and "mailto:" URIs.

validation?

"strict" | "lax" | "preserve" | "strip"

Requires Saxon-PE or Saxon-EE.

type?

eqname

Determines what happens to any type annotations on element or attribute nodes. Requires Saxon-PE or Saxon-EE.

recoverable?

boolean

method?

{ "xml" | "html" | "xhtml" | "text" | eqname }

Serialization attribute. May be an AVT, so the values can be decided at run-time. Any values specified on the xsl:result-document instruction override the values specified on the xsl:output declaration.

byte-order-mark?

{ boolean }

cdata-section-elements?

{ eqnames }

doctype-public?

{ string }

doctype-system?

{ string }

encoding?

{ string }

escape-uri-attributes?

{ boolean }

html-version?

{ decimal }

include-content-type?

{ boolean }

indent?

{ boolean }

Serialization attribute. May be an AVT, so the values can be decided at run-time. Any values specified on the xsl:result-document instruction override the values specified on the xsl:output declaration.

item-separator?

{ string }

media-type?

{ string }

normalization-form?

{ "NFC" | "NFD" | "NFKC" | "NFKD" | "fully-normalized" | "none" | nmtoken }

omit-xml-declaration?

{ boolean }

parameter-document?

{ uri }

standalone?

{ boolean | "omit" }

suppress-indentation?

{ eqnames }

undeclare-prefixes?

{ boolean }

use-character-maps?

eqnames

output-version?

{ nmtoken }

Notes on the Saxon implementation

Since Saxon 9.5, the xsl:result-document instruction in Saxon-EE is asynchronous. That is, the code to output the result document runs in a separate thread, in parallel with other processing. The maximum number of threads used by xsl:result-document instructions is limited by the configuration option FeatureKeys.RESULT_DOCUMENT_THREADS which defaults to the number of processors available to the Java VM; setting this to zero or one will suppress multithreading. Setting FeatureKeys.ALLOW_MULTITHREADING to false has the same effect. (This can be useful when debugging, because otherwise the output from xsl:message and fn:trace() can be very confusing).

Asynchrony can also potentially cause problems if the code calls extension functions that have side-effects. Multi-threading can therefore be controlled, if required, using the saxon:asynchronous attribute on the xsl:result-document instruction: use saxon:asynchronous="no" to suppress multi-threading. Asynchronous processing of xsl:result-document is automatically suppressed if tracing (using a TraceListener) is enabled.

The xsl:result-document instruction may also take the extension serialization parameter saxon:indent-spaces. This attribute may be an AVT, so the values can be decided at run-time. Any values specified on the xsl:result-document instruction override the values specified on the xsl:output declaration.

Details

The xsl:result-document element was introduced in XSLT 2.0, replacing the previous extension element saxon:output.

The destination of the result document can be altered programmatically by defining an OutputURIResolver. In the absence of an OutputURIResolver, the document is serialized and written to the file identified by the URI in the href attribute, resolved if it is relative against the base output URI for the transformation (which defaults to the destination of the principal output document). The destination must use the file:/ URI scheme. Any previous file at this location is overwritten. If the transformation fails with a dynamic error, the content of any output files is undefined (no attempt is made to reset them to their original state).

Examples

In the following, the body of the preface is directed to a file called preface.html (prefixed by a constant that supplies the directory name). Output then reverts to the previous destination, where an HTML hyperlink to the newly created file is inserted.

<xsl:template match="preface"> <xsl:result-document href="{$dir}/preface.html" method="html"> <html><body bgcolor="#00eeee"><center> <xsl:apply-templates/> </center><hr/></body></html> </xsl:result-document> <a href="{$dir}/preface.html">Preface</a> </xsl:template>

Links to W3C specifications

XSLT 2.0 Specification

XSLT 3.0 Specification

See also

xsl:output