This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29990 - [XSLT30] result documents in temporary trees and in patterns as a result of fn:transform calls
Summary: [XSLT30] result documents in temporary trees and in patterns as a result of f...
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Windows NT
: P2 major
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-08 09:44 UTC by Abel Braaksma
Modified: 2016-12-01 18:03 UTC (History)
1 user (show)

See Also:

Attachments

Description Abel Braaksma 2016-11-08 09:44:39 UTC 
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.
Comment 1 Michael Kay 2016-11-08 11:44:57 UTC 
The problem of fn:transform having side-effects (with the "saved" option) was discussed and resolved in the closure of bug #29951.
Comment 2 Josh Spiegel 2016-11-08 14:55:10 UTC 
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.
Comment 3 Michael Kay 2016-11-08 14:59:43 UTC 
Then I suggest you (one of you) should reopen bug #29951 rather than opening new issues.
Comment 4 Abel Braaksma 2016-11-08 16:06:18 UTC 
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.
Comment 5 Abel Braaksma 2016-11-08 16:08:19 UTC 
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.
Comment 6 Abel Braaksma 2016-12-01 11:00:14 UTC 
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.
Comment 7 Michael Kay 2016-12-01 18:03:02 UTC 
The WG decided this is fixed by virtue of the resolution to bug #29951