This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Certain combinations of updates - notably, creating two attributes with the same name on the same element - are errors only by virtue of a rule that the data model must satisfy all constraints described in the XDM spec. It is not clear whether these consistency constraints apply (a) in a subtree rooted at a node that is deleted in the course of the update (b) in a subtree rooted at a node that is replaced in the course of the update. For example, there is nothing to stop you creating two same-named attributes for an element E that is itself the target of a delete or replace node expression; it is not clear whether this is an error or not. The answer depends on whether we believe that a node still exists after it has been deleted or replaced. Clearly if it doesn't exist, then there can be no consistency rules applied to it. Intuitively, we might think that a node continues to exist after a replace operation but does not continue to exist after a delete: however, those are intuitions based on the choice of English keywords in the syntax, not on anything stated formally in the semantics.
I believe the specification deliberately chose wording to make it understood that a "deleted" sub-tree may certainly continue to exist. Whether or not it actually does seems down to the embedding environment.
After extensive discussion, the WG resolved that the constraint in upd:applyUpdates() should be deemed to apply to all nodes, including deleted/detached nodes. Something like: change: 5. If the resulting XDM instance violates any constraint to: 5. If after applying the updates, any XDM instance (including a node in a tree that has been deleted or detached) violaties any constraint...
Sorry I was late to the meeting... but if I have an update statement that adds a new attribute and deletes one of the same name, why would that have to be violating the constraints? The result is consistent. Or is it ok because the deleted/detached attribute is not a duplicate named attribute anymore?
Regarding comment #3, that situation doesn't leave anything inconsistent (it would only be a transient inconsistency, and that's not what the debate is about). The situation under debate is adding two attributes of the same name to an element, and then deleting or detaching the element - is the deleted element required to be consistent at the end of the day?
Well, I think we are starting to overspecifying. If the deleted element has been removed, then obviously the data model is still consistent. If the element has been detached (meaning is not part of the data model instance but a seperate data model instance), then there will be an inconsistency in the detached data model instance...
Action A-392-19: I was asked to propose precise text to implement the decision recorded in comment #2. Here goes: In 3.2.2 upd:applyUpdates, section "Semantics", rule 5, change the rule from <old> If the resulting XDM instance violates any constraint specified in [XQuery/XPath Data Model (XDM)], a dynamic error is raised [err:XUDY0021]. </old> to <new> If, after applying the updates, any XDM instance (including a node that has been deleted or detached from its parent, or that is a descendant of such a node) violates any constraint specified in [XQuery/XPath Data Model (XDM)], a dynamic error is raised [err:XUDY0021]. </new>
On 17 March 2009 the WG accepted the proposed wording in comment #6