This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Insert into should preserve the order of an inserted sequence. Users can always use insert unorder { expr } into target if the order of the inserted sequence should be implementation-dependent. Proposed change: "Semantics The semantics of upd:insertInto are identical to the semantics of upd:insertBefore, except that $target is substituted everywhere for parent($target), and Rule 2a is changed as follows: The children property of $target is changed to include the nodes in $content. The order among the new children, and their position within the parent node, is implementation-dependent." to "Semantics The semantics of upd:insertInto are identical to the semantics of upd:insertBefore, except that $target is substituted everywhere for parent($target), and Rule 2a is changed as follows: The children property of $target is changed to include the nodes in $content. The new sequence of children is inserted at an implementation-dependent location among the parent node's children, preserving the sequence and its order."
I am concerned about the proposed phrase "... preserving the sequence and its order." In general, we cannot guarantee that an inserted sequence will be preserved without interleaving. For example, suppose that one expression inserts the node sequence (A, B) and another expression inserts the node sequence (C, D). If (A, B) is inserted first and the other insertion specifies "into" only, a possible outcome is (A, C, D, B). I do not see any practical way to prevent this. Therefore I think we can claim that order is preserved among the nodes inserted by a single expression, but I do not think we can claim that "the sequence" is preserved (in the sense of protecting it against interleaves). --Don
Ok. I agree with into. However I still think as first/as last should not allow interleaving.
Michael, I believe that this bug report is resolved by the changes that were agreed to in order to resolve Bug 4527. Therefore I have marked this bug report as "Fixed". Please examine the changes listed under Bug 4527, and if you agree, change the status of this bug report to "Closed". Regards, Don Chamberlin (for the Query Working Group)