In [8.2.3 upd:applyUpdates], semantic rules specify the order in which the update primitives on a pending update list are applied. The purpose of this ordering is to ensure that the result of applying the pending update list is deterministic. The order of application of the update primitives was derived from the following reasoning:
insertAttribute
, replaceValue
, and rename
primitives do not conflict with any
other primitives other than put
.
insertInto
primitives must be applied before insertIntoAsFirst/Last
and
insertBefore/After
primitives. Reason: if an unpositioned insert were applied after a
positioned insert, it might interfere with the position established by the earlier
positioned insert.
For example, suppose node A is inserted "before" node B.
A later unpositioned insert into the common parent of A and B might intervene between
A and B,
which is not allowed by the semantics of "insert before."
insertBefore/After
primitives must be applied before replaceNode
primitives.
Reason: After a node has been replaced, it no longer has a parent, so "before" and
"after" the replaced node
are no longer defined.
insertIntoAsFirst/Last
primitives must be applied before replaceElementContent
primitives.
Reason: this was a decision of the working group.
The intent of this decision is that, if both of these primitives are applied to the
same target node in a query,
the effective result is determined by the replaceElementContent
primitive.
replaceNode
primitives must be applied before replaceElementContent
primitives.
Reason: if element content that includes a node N has been replaced, then N no longer
has a parent.
In this case, "replace node N" is undefined.
replaceNode
primitives must be applied before delete
primitives. Reason: After a node has been
deleted, it no longer has a parent. Replacing a node that has no parent is undefined.
put
primitives must be applied after all other primitives in order that
documents stored by a snapshot will reflect all update operations applied by the snapshot.