[Bug 4312] [Update] Double deletion of a replaced node

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4312

           Summary: [Update] Double deletion of a replaced node
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Update Facility
        AssignedTo: andrew.eisenberg@us.ibm.com
        ReportedBy: chamberl@almaden.ibm.com
         QAContact: public-qt-comments@w3.org


In Section 3.1.8, upd:replaceNode, we see the following rules:

Rule 3 says that the target node (i.e., the node that was replaced) is "marked
for deletion". 

Rule 4 says that the parent of the target node is updated so that the target
node is no longer among its children or attributes.

But in the semantics of upd:applyUpdates, after all the primitive operations
have been applied, we get around to processing the nodes that are "marked for
deletion", and for each of these nodes, we update its parent so that the
"marked" node is no longer among its children or attributes.

The problem here is that, in the case of a node that is replaced, the node gets
removed from its parent twice: once by Rule 4 of upd:replaceNode, and once by
Rule 2e of upd:applyUpdates.

I think the way to fix this redundancy is to change Rule 3 of Section 3.1.8
(upd:replaceNode) as follows:

3. Effect on $target: The parent property of $target is set to empty.

In this way, the job of detaching $target from its parent is done entirely by
upd:replaceNode, and we no longer mark the replaced node for later deletion.
The redundant operation on the parent of the deleted node disappears.

It is interesting to note that, when update primitives are applied in Section
3.2.2 (upd:applyUpdates), replaceNode primitives (Rule 2c) are applied before
replaceElementContent primitives (Rule 2d). It is possible that both of these
primitives might apply to the same node. In this case, Rule 2c will detach the
node from its parent (but the node and its nodeid will still exist, without any
parent), and then Rule 2d will replace the content of the node (this is a
harmless thing to do but the modified node can no longer be reached from its
parent.)

I request that the working group consider this proposal to modify Rule 3 of
Section 3.1.8 as described above.

Regards, 
--Don Chamberlin

Received on Thursday, 8 February 2007 23:57:41 UTC