29990 2016-11-08 09:44:39 +0000 [XSLT30] result documents in temporary trees and in patterns as a result of fn:transform calls 2016-12-01 18:03:02 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED FIXED P2 major --- 1 abel.braaksma mike josh.spiegel public-qt-comments oldest_to_newest 128107 0 abel.braaksma 2016-11-08 09:44:39 +0000 A FO31 bug 29959 comment#8 made me realize that we have carefully crafted rules for side-effects to *never* happen while evaluating patterns or temporary result trees. But I don't think we ever imagined a function fn:transform, which is now part of FO31. Since use of functions is not restricted, one could write, for instance: <xsl:template match="foo/bar[fn:transform(....) = 12]"> .... </xsl:template> If the transformation has a side effect, what would happen? This transformation could be evaluated once, never, many times, be cached, write messages, result documents, principal results etc. I think we either may have to prohibit this, or make sure that result documents are not created in such cases (for instance by requiring that serialization be disabled in such execution contexts). A similar thing applies to xsl:evaluate calling this function, or a dynamic function call effectively calling this function. 128108 1 mike 2016-11-08 11:44:57 +0000 The problem of fn:transform having side-effects (with the "saved" option) was discussed and resolved in the closure of bug #29951. 128110 2 josh.spiegel 2016-11-08 14:55:10 +0000 I think the decision to preserve "saved" (side-effects) in any form is objectively wrong. It would, for example, be trivial to write valid tests that no reasonable implementation would pass. Or, write tests where many reasonable implementations would produce completely different but valid results. Or, more importantly, write tests where valid results are unintuitive to users. 128111 3 mike 2016-11-08 14:59:43 +0000 Then I suggest you (one of you) should reopen bug #29951 rather than opening new issues. 128114 4 abel.braaksma 2016-11-08 16:06:18 +0000 I'm not sure any F&O resolution will remove the requirement to prohibit (or not?) the use of this function in cases where we have previously prohibited creating result documents. 128116 5 abel.braaksma 2016-11-08 16:08:19 +0000 One way forward is, for instance, to require XSLT processors to raise FOXT0007 in such cases, normatively, so that it won't be an implementation-defined/dependent behavior. 128272 6 abel.braaksma 2016-12-01 11:00:14 +0000 Update: the proposal in F&O Bug 29951, comment#11 removes the problem of side-effects in temporary output state to an implementation-defined function. The proposed solution is for fn:transform to call a function for each result document, which itself can be defined as an option to fn:transform. This function may or may not be implementation-defined and/or have side effects. This in itself creates a peculiar situation: if called from an XSLT stylesheet, that stylesheet will *not* be able to save the results through such function (unless it uses implementation extensions), because a function call operates in a temporary output state. A workaround would be to write stylesheets that return all result documents as part of the principal result. Another workaround would be for XSLT to define an extra parameter for the $options of fn:transform, for instance to define a template, named output definition or mode, which receives the result. This would then in turn "inherit" the output state the call itself is in. 128274 7 mike 2016-12-01 18:03:02 +0000 The WG decided this is fixed by virtue of the resolution to bug #29951