This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Under xsl:result-document the spec states: <quote> The instructions in the initial template are evaluated in final output state. An instruction is evaluated in the same output state as its calling instruction, except that xsl:variable, xsl:param, xsl:with-param, xsl:attribute, xsl:comment, xsl:processing-instruction, xsl:namespace, xsl:value-of, xsl:function, xsl:key, xsl:sort, and xsl:message always evaluate the instructions in their contained sequence constructor in temporary output state. </quote> This list of instructions has not been revised since 2.0. The most obvious candidates to add to the list are xsl:assert and xsl:merge-key. xsl:map and xsl:map-entry might also be considered. However, I wonder whether the list couldn't be shortened? Why do we allow xsl:result-document to be executed during evaluation of xsl:element but not during evaluation of xsl:attribute? I can't think of a defensible reason. I would be inclined to reduce the list to xsl:variable, xsl:param, xsl:with-param, xsl:function, xsl:key, xsl:sort, xsl:merge-key. This basically catches most places where it's unpredictable whether the instruction will be executed or not. (Note: I've discovered that Saxon doesn't enforce the rules as strictly as described in the spec, though that's not the primary motivation for this bug report. It's easy to enforce the current restrictions and I was halfway through doing so when I realised that the rule needed to be re-assessed for 3.0)
We discussed various ways of reducing the inconvenience of the current restrictions on xsl:result-document without reducing interoperability. We're inclined towards adding an attribute (say deterministic="no") on xsl:result-document whose effect is (a) to mean that it's not an error to use it in temporary output state, and (b) to remove the restriction on writing to the same URI more than once. The effect of setting this would, of course, be to accept reduced interoperability - in effect xsl:result-document would then have the same status as calls to side-effecting extension functions. If temporary output state is retained then it should be extended to places like xsl:merge-key. We could remove the restriction from xsl:attribute, xsl:comment etc but there's not much point: it wouldn't benefit users. It's xsl:function where the resl restriction lies.
Other thoughts are that for diagnostic output use cases, extending xsl:message e.g. to take a URI destination as an attribute, and to append rather than overwite this destination, might be appropriate.
The proposal in the penultimate paragraph of comment 0 was accepted, and has been applied.