This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider "insert node". It appears that it is not intrinsically an error to write insert nodes (@code, @code) into $element that is, to insert two attributes with the same name into the same element. It only becomes an error (XUDY0021) if the total set of updates makes the data model inconsistent, that is, if $element is not deleted in the course of the update. This similarly applies to an attempt to create two same-named attributes using "replace node", or using a combination of multiple insert/replace/rename expressions. Now contrast this with insert (2.4.1) rule 4c: "Multiple attribute nodes in $alist may not have QNames whose implied namespace bindings conflict with each other [err:XUDY0024]." This says that the following is an error insert nodes ( attribute {QName("http://one/", "a:att")}{0}, attribute {QName("http://two/", "a:att")}{0} ) into $element whether or not $element gets deleted during the course of the update. It's also an error to do the same thing in a sequence of separate "insert" expressions. Logically, it makes no sense to treat these two cases differently. In the interests of usability, I think it makes sense to disallow creation of a pending update list that adds two same-named attributes to the same element, irrespective of whether the PUL contains a delete action for that element or one of its ancestors. I would propose adding the following rules: 2.4.1 rule 4c: "Attribute nodes in $alist must have distinct names [err:TBA]". 2.4.3.1 rules 4c: "Attribute nodes in $rlist must have distinct names [err:TBA]" 3.2.1 rule 2f: "Two or more primitives on the merged list create conflicting attributes for the same element node [err:TBA]. Two attributes conflict if they have the same node name. The following kinds of primitives can contribute to such a conflict: upd:insertAttributes, upd:replaceNode, and upd:rename." 3.2.2 rule 1f: "Two or more primitives on $pul create conflicting attributes for the same element node [err:TBA]. Two attributes conflict if they have the same node name. The following kinds of primitives can contribute to such a conflict: upd:insertAttributes, upd:replaceNode, and upd:rename." [I appreciate that this is a bad time to raise this. Sorry!] Michael Kay
Strictly speaking that in the upd:applyUpdates section, it is clear that any XQDM viloation that resulting XUDY0021 to be raised is done after all the pending update list application is applied. Therefore, if there are some temporary duplicate attribute name constraint occurs, the error would not be raised if these faulty attribute nodes are under a node that is eventually deleted in the last step of the upd:applyUpdates. So any in-flight checking of duplicate attribute node names could not raise errors immediately. However, I completely understand your motivation of raising this issue as this would cause quite expensive checking in the end if such duplicate attribute name nodes errors are held until the end of the upd:applyUpdates. However, attempting to re-arranging the update application order to move 'upd:delete' ahead may be too late. Yet, I like your proposal in http://www.w3.org/Bugs/Public/show_bug.cgi?id=6481, that is, to make inflight duplicate attribute name check feasible. This makes senses and it is not too late to change this. Note lately, the new tests attriubte-errors[1-5] starts to test these conditions, however, at least in these tests, there is no delete in the end. So in-flight duplicate attribute name nodes checking is still feasible. However, for the new tests you added applyUpdates-02[1-6], these issues show up clearly.
The WG decided that there was no consensus to make this change at this stage of the game. Note that bug #6495 is relevant; the question is still open at the time of writing whether deleted/replaced subtrees must be consistent.
Note that although the WG resolved not to fix this, it was in fact fixed as a side-effect of the fix to bug #6495: because deleted elements have to be consistent, inserting two like-named attributes into an element will now fail in all circumstances, whether or not the containing element is deleted.