[Bug 29951] [FO31] fn-transform "saved"

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29951

--- Comment #11 from Michael Kay <mike@saxonica.com> ---
After discussion on today's telcon, I propose the following resolution:

(a) drop the option delivery-format=saved.

(b) add a new option post-process. The value is a function of type

function(xs:anyURI, item()*) as item()*

with the default value

function($a, $b) { $b }

which is invoked to post-process each result of the transformation (both the
principal result and secondary results), in whatever form it would otherwise be
delivered (document, serialized, or raw). The first argument of the function is
the URI of the result, the second argument is the actual value. The value that
is returned in the result of the fn:transform function is the result of
applying this post-processing.

<note>
<p>If the implementation provides a way of writing or invoking functions with
side-effects, this post-processing function might be used to save a copy of the
result document to persistent storage. For example, if the implementation
provides access to the EXPath File library [non-normative reference], then a
serialized document might be written to filestore by calling the
file:write-binary function. Similar mechanisms might be used to issue an HTTP
POST request that posts the result to an HTTP server, or to send the document
to an email recipient. The semantics of calling functions with side-effects are
entirely implementation-defined.</p>

<p>If the primary purpose of the post-processing function is achieved by means
of such side-effects, and if the actual results are not needed by the caller of
the fn:transform() function, then it does not matter what the post-processing
function actually returns (it could be an empty sequence, for example).</p>

<p>Calls to fn:transform can potentially have side-effects even in the absence
of the post-processing option, because the XSLT specification allows a
stylesheet to invoke extension functions that have side-effects. The semantics
in this case are implementation-defined.</p>

<p>Unless implementations provide mechanisms such as pragmas or function
annotations to allow functions with side-effects to be specially recognized, it
is advisable that calls to fn:transform should appear in a context where the
result of the function is actually used, otherwise there is a risk that an
optimizer might decide to eliminate the function call.</p>

</note>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 15 November 2016 18:17:57 UTC