This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Are there any special considerations when mixing fn:put with transform expressions? Example 1 --------- copy $dummy := <dummy /> modify fn:put(<new-document />, "output.xml") return local:non-updating-query() This stores an element in output.xml but also returns the result of executing a non-updating query. It seems a little unfortunate that this 'dummy' is required to mix fn:put with a non-updating query - although since this is essentially an expression with side effects, perhaps that's no bad thing. Example 2 --------- let $original := doc('update.xml') return copy $doc := $original modify (insert node <node /> into $doc/nodes, fn:put($doc, "update.xml")) return $original This example reads and writes the same resource. In XSLT, there is a specific (recoverable) error which mentions a similar situation with xsl:result-document. [ERR XTRE1500] It is a recoverable dynamic error for a stylesheet to write to an external resource and read from the same resource during a single transformation, whether or not the same URI is used to access the resource in both cases. Example 3 --------- copy $doc := doc('update.xml') modify (insert node <node /> into $doc/nodes, fn:put($doc, "update.xml")) return (count($doc/nodes/node), count(doc('update.xml')/nodes/node)) Because 'doc' is stable the two calls to doc must return the same result, even though an update has occurred. Example 4 --------- copy $doc := <a /> modify (fn:put($doc, "update.xml")) return doc('update.xml') Does doc('update.xml') see the newly created resource, or the original resource (if we assume one was available)?
Has there been any more discussion on this issue? I would even suggest to completely disallow fn:put() functions inside transform expressions in order to reduce the chance of indeterministic, implementation-dependent behavior. For example, in the following example.. copy $a := <a/> modify fn:put($a, "1") return (), copy $b := <b/> modify fn:put($b, "2") return () we will have no guarantee if $a or $b will be found in the final result.
The WG hasn't discussed bugs against XQuery Update 1.0 for quite some time due to a focus on XQuery 3.0.
The Working Group has decided that it is an error if the modify clause of a transform expression produces a upd:put primitive.
I'm reopening, as I'm unable to find the agreed change in the XQuery Update 3.0 editor's draft.
I'm closing this bug again, as the decision is recorded in changes.txt and will be made in the course of time.