This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The delete expression allows multiple nodes to be deleted; the rename expression only allows a single node to be renamed. It's hard to see any reason for this asymmetry. If I can do delete nodes //@PRICE then why can't I do rename nodes //@PRICE as xs:QName("COST") The workaround is easy, but we shouldn't be tripping our users up with unnecessary differences between two very similar expressions. Of course, the next thing the user will try to do is: replace value of nodes //@DISCOUNT with 0.00 which also seems reasonable...
Michael, I am not enthusiastic about allowing all our updating expressions to operate on multiple target nodes. The semantics of such a feature would be quite complex. In general, the target expression of an update may return a mixed sequence of different kinds of nodes (elements, attributes, etc.) The semantics of updates for the various types of nodes are different (for example, you can insert into an element but not into an attribute; you can replace an attribute only with another attribute; renaming an attribute may need special rules for namespaces as you observed in Bug 5316; etc.) Specifying the semantics of updates on sequences of nodes would be a nightmare. It would also contradict the XQuery philosophy (frequently espoused by you, Michael) of simple, composable expressions (e.g., use a FLWOR to update multiple nodes.) You might reasonably argue that, for consistency, we should not allow a delete expression to operate on multiple nodes, even though the semantics of multiple deletions are harmless and straightforward. I would be inclined to retain multiple deletions since they have been in the spec for a long time and are well understood. The work of removing them from the spec and the test suite at this point seems to have a pretty low return on investment. But if consistency is our highest priority, I would much rather remove multiple deletions than try to specify the semantics of multiple-everything-else. --Don Chamberlin (speaking for myself)
On 15 Jan 2008, the working group decided to close this bug report without changes to the existing specification, for the reasons outlined in Comment #1. Michael, since you were present at the discussion, I am marking this bug report as Closed. --Don Chamberlin (for the Query Working Group)