This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
xsl:output and xsl:result-document have an attribute parameter-document which is the URI of a file containing serialization parameters. In the case of xsl:result-document, the attribute is an AVT, so there is a clear implication that we don't know the URI until run-time and therefore we don't read the parameter document until run-time. For xsl:output the attribute is known statically, but we don't give any indication of whether we expect the parameter document to be read at compile time or at run-time. If we leave this question open, we create a potential interoperability problem, especially in the context of distributable packages (this also affects the location of the parameter file). For some reason I don't fully understand, we always resisted making the serialisation attributes on xsl:output dynamic (AVTs). Is the introduction of parameter documents supposed to circumvent that restriction? In keeping with the current status of serialization properties, I'm inclined to say that we add the rules: * For xsl:output, processors should read the supplied parameter file during static analysis of the stylesheet; subsequent changes to the content of the file should have no effect. * For xsl:result-document, processors should read the supplied parameter document during the evaluation of the xsl:result-document instruction. If the same parameter file (that is, the same absolute URI) is used in the course of repeated evaluation of one or more xsl:result-document instructions, it is implementation-dependent whether any changes to the content of the file after the first use have any effect. (Alternative resolution: scrap the feature. We currently have no tests, it delivers very little benefit, and it's complexity we can do without.)
I believe this requirement was added to allow for the serialization feature that is described in: http://www.w3.org/TR/xslt-xquery-serialization-30/#serparams-in-xdm-instance > we always resisted making the serialisation attributes on xsl:output > dynamic (AVTs) I often wondered the same thing. Perhaps because none of our declarations have it? But we now have shadow attributes, which I think suffice. I think we should best resolve this by saying that: 1) For xsl:output, the parameter document must be part of the statically available documents and is retrieved using the same semantics as for the fn:doc() function. If the document is not part of the statically available documents, the result is an empty sequence / error. 2) For xsl:result-document, the parameter document is retrieved using a dynamic call on the fn:doc() function and follows the same semantics in terms of stability. This allows for proper precompilation of packages, as a processor can simply add the declarations statically for xsl:output (i.e., if the document is there at compile time, it does not have to be there at run time). It then works the same way as if someone had written (using his own format of parameter document): <xsl:output _method="{doc('settings.xml')/output/method}" />
Proposal: (A) In ยง26, xsl:output, change the paragraph If present, the URI supplied in the parameter-document attribute is dereferenced, after resolution against the base URI of the xsl:output element if it is a relative reference. If the location of the stylesheet at development time is different from the deployed location, any relative reference should be resolved against the deployed location. A serialization error occurs if the result of dereferencing the URI is ill-formed or invalid; but if no document can be found at the specified location, the attribute may be ignored. to read If present, the URI supplied in the parameter-document attribute is dereferenced, after resolution against the base URI of the xsl:output element if it is a relative reference. The parameter document SHOULD be read during static analysis of the stylesheet. A serialization error occurs if the result of dereferencing the URI is ill-formed or invalid; but if no document can be found at the specified location, the attribute SHOULD be ignored. [SHOULD rather than MUST because it can be hard to distinguish an absent document from an invalid document, since many sites return an "error page" rather than a 404.] (B) In 25.1, xsl:result-document, change the paragraph If present, the effective value of the URI supplied in the parameter-document attribute is dereferenced, after resolution against the base URI of the xsl:result-document element if it is a relative reference. If the location of the stylesheet at development time is different from the deployed location, any relative reference should be resolved against the deployed location. A serialization error occurs if the result of dereferencing the URI is ill-formed or invalid; but if no document can be found at the specified location, the attribute may be ignored. to read If present, the effective value of the URI supplied in the parameter-document attribute is dereferenced, after resolution against the base URI of the xsl:result-document element if it is a relative reference. The parameter document SHOULD be read during run-time evaluation of the stylesheet. If the location of the stylesheet at development time is different from the deployed location, any relative reference SHOULD be resolved against the deployed location. A serialization error occurs if the result of dereferencing the URI is ill-formed or invalid; but if no document can be found at the specified location, the attribute SHOULD be ignored.
The proposal was accepted and the changes have been applied.