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

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 01 Jul 2015 13:30:44 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-24040-523-Akt3BmI66Z@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24040

--- Comment #7 from Michael Kay <mike@saxonica.com> ---
Concerning 1101 (discussed in comment 2 but misspoken as 1107):

I think it's not clear that the XSLT spec gives you license to inline the
variable, or at any rate, to skip setting temporary output state when you do
so. It would be allowed in XPath under the "Errors and Optimization" rules, but
XSLT does not reference these rules, nor does it provide any equivalent of its
own. In the absence of such a rule, any rewrite you perform must preserve error
semantics, which means that when inlining the variable you must still set
temporary output state.

I have an open mind about whether XSLT should adopt the XPath rules and/or
allow some other relaxation here. But I think the status quo is that it does
not. I think the whole point is that xsl:result-document has a (limited kind
of) side effect, and the rules on temporary output state are trying to ensure
that calls on result-document are guaranteed to fail if they appear in places
where execute-once semantics are not guaranteed; if we relax the rules, we lose
interoperability.

(Saxon, I believe, inlines the variable but in such a way that temporary output
state is still set.)

Concerning 1107, I have replaced the call on rrr with a call on a new template
whose result depends on the context item, so that a processor cannot take
advantage of the fact that the called template produces the same sort key each
time. (Incidentally, the optimization wouldn't work in 3.0 anyway, as the
called template can be overridden in a different package by one that uses the
context item.)

Concerning 1109 and 1110, I have fixed the tests so that the parameter value is
used, which I believe forces the error.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 1 July 2015 13:30:47 UTC

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