W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2015

[Bug 24040] [XT3TS] result-document-1107, 1109, 1110

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 May 2015 01:30:26 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24040-523-0FFj1i6qYL@http.www.w3.org/Bugs/Public/>

--- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
>    <xsl:template name="a">

That template is used by test result-document-1101, not 1107, the latter using
the sort as mentioned in comment#0.

That is not to say that in 1101 the same issue applies. And I'm not certain
whether using the variable twice really forces this error, it can still be
rewritten by inlining if a processor chooses so, i.e. like:

    <xsl:call-template name="rrr" />
    <xsl:call-template name="rrr" />

Looking further into these tests, I see that more tests here are eligible for
improvement: i.e., xsl:attribute no longer triggers temporary output state in
XSLT 3.0 (test 1102), or specifically:

The instructions in the initial named 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:function,
xsl:key, xsl:sort, xsl:accumulator-rule, and xsl:merge-key always evaluate the
instructions in their contained sequence constructor in temporary output state.

Looking at that quote, I am wondering whether or not we should improve the text
in the spec,

1. saying that optimizing rewrites may remove this error from occurring
2. or: saying that optimizations must leave this error in place at all times
(but I don't like this option)

With the variables, the indirectness is an issue. I.e., suppose a processor
aggressively inlines variables, this error would only be detectable if it
xsl:result-document is statically inside xsl:variable's scope.

But there's another problem here: aftger optimization, the xsl:result-document
is positioned in a legal position and the result-document is created, possibly
repeatedly (which yields a different error). This is a processor-dependent
behavior that may not be what we want.

Perhaps we should lift this error entirely and change it such that in temporary
output state, xsl:result-document is ignored, with a NOTE saying that as a
result of optimizations, temporary output state may change into final output
state, potentially leading to multiple invocations of the same
xsl:result-document instruction, raising XTDE1490.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 19 May 2015 01:30:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:54 UTC