This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Some gaps in the the specification of fn:put(): (a) it nowhere says whether this is an updating expression or not. Presumably this means it isn't. But it behaves in many ways like an updating expression; I would have thought it should be one. (b) it says "The results of fn:put do not become effective until after completion of the query", but it doesn't actually say what is probably intended, which is that the node that is serialized is the post-update node, rather than the pre-update node. (c) It's not clear why put() doesn't use the pending update list in the same way as other updating expressions, and why it's not subject to similar conflict analysis (for example writing two different nodes to the same URI) (d) There seem to be no special static typing rules. Since the static type of put() is always empty-sequence(), it would seem that under static typing it is always an error.
Yupp, making fn:put an updating expression has been suggested a couple of times, and its low amount of specification has been pointed out too: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5314 Don's summary in 5314 isn't very useful in my opinion, essentially stating that things are as they are because they were written as so, not detailing the reasoning behind it. Leaving conflict analysis(or just in general having fn:put() an update operation and hence within the "update framework") implementation defined has negative impacts on interoperability, so the advantages it brings must be strong and clear to outweight it. Currently I don't see how conflict analysis would constrain implementers, but rather that it would make the language more predictable for users.
Thanks for the reference to bug #5314 - I felt sure these issues had been raised before but failed to locate the bug. To be more specific, I am having a correspondence with a user who is expecting to use fn:put() in a context where an updating expression is expected, and argues this is legal on the grounds that the semantics are implementation-defined, and this is a semantic rule. I think that if the WG had intended to allow this then it would have said so. On the other hand, I find it hard to think of any reason why the WG would have not wanted to do this. This function sticks out like a sore thumb, it clearly hasn't been thought through. And there don't appear to be any test cases for it.
One can contrast to how XSL-T 2.0 handles multiple invocations: [ERR XTDE1490] It is a non-recoverable dynamic error for a transformation to generate two or more final result trees with the same URI.
I've raised this before as well in Bug #4167. a) I believe that fn:put() should be an updating expression - it makes no sense for it not to be. b) I don't think it's obvious that fn:put() should "serialize" post-update nodes - XQilla currently returns pre-update copies of nodes passed as arguments to fn:put(). c) It would be helpful if fn:put() was described in terms of the pending update list, and if that was used to resolve conflicting put operations. d) Many useful queries don't pass the pessimistic XQuery static typing rules :-(.
This bug report was discussed by the Query Working Group on 3 June 2008 and resolved as follows: (a) fn:put() is an updating expression. (b) Rather than operating immediately on a node, fn:put() will add a new updating primitive to the Pending Update List. This updating primitive will be applied only after all other updating primitives on the PUL have been made effective. The result will be that fn:put() will effectively apply to the post-updated nodes. If a user wants to invoke fn:put() on a pre-updated node, he will first need to make a copy of that node, possibly by using a vacuous transform. (c) It is an error for two invocations of fn:put() in the same snapshot to operate on the same nodeid. (d) fn:put(), like all other updating expressions, is allowed to return an empty XDM without raising a static error (see Bug 5700). Michael Kay, if this resolution is acceptable to you, please change the status of this bug to Closed. Regards, Don Chamberlin (for the Query Working Group)
Correction after reviewing the minutes of the working group meeting: Item (c) in Comment #5 should read as follows: (c) It is an error for two invocations of fn:put() in the same snapshot to operate on the same URI (after any necessary resolution of relative URIs.)