Re: Removed nodes and Mutation Summary

Skip to first unread message

Rafael Weinstein

Mar 31, 2012, 3:45:16 PM3/31/12
to Clemens Nylandsted Klokmose,
Hi Clemens,

Interesting use case. Thanks for making contact.

[Note that I have updated mutation-summary-discuss so that anyone can
join and cc'd there so that everyone can have the benefit of this

I had wondered if this issue would come up. You are correct that
internally, for nodes which have been moved, the library is tracking
each node's oldParentNode. It is also the case that for the { all:
true } query, that the set of |reordered| nodes is calculated. In
doing so, each moved node's oldPreviousSiblingNode is calculated.

I've added support for retrieving this data to the library. All
summaries now come with a 'getOldParentNode' function. This will
retrieve this parentNode in the previous state. Note that this only
works if the node in question started off reachable from the root in
the previous state (because otherwise, the mutation summary may not
have complete information about it). In practice, this means that you
should only ever ask for oldParent if the node in question was
reported to be |removed| or |reparented|.

Likewise, I've added a 'getOldPreviousSibling' to summaries responding
to 'all' queries. This behaves as you would expect and throw if the
node in question was *not* reported in the 'reordered' element array.

I've updated the APIReference wikipage here to reflect these changes:

It's nice to see research activity in this area. I'm happy to help out
where I can. Let me know how it goes for you.


p.s. As you may have discovered, there are multiple valid approaches
to tree mirroring and each has trade-offs. The TreeMirror utility
class implements one such strategy -- which relies on maintaining a
mapping between the local node and the remote node.

On Sat, Mar 31, 2012 at 7:41 AM, Clemens Nylandsted Klokmose
<> wrote:
> Hi Rafael,
> I've just started using your Mutation Summary library for a research
> project, and it is really a great library!
> I am trying to manage a two-way mapping between a part of the DOM and a
> JsonML datastructure.
> However, I have run into the problem that when a node is removed from the
> DOM, it will be part of the removed list of the summary, yet I don't seem to
> have info regarding where in the DOM it was removed. Hence, I am not able to
> remove the corresponding node in the json representation.
> I've looked a bit in the mutation summary source, and it seems that
> information regarding a removed nodes previous and next siblings are
> available at some point, is there somehow I can access this information when
> I get the summary?
> Thanks,
> Clemens
> --
> Clemens Nylandsted Klokmose, PhD         email:
> Department of Computer Science         web:
> Aarhus University         mobile: +45 28556442
> Aabogade 34, DK-8200 Aarhus N, Denmark

Reply all
Reply to author
0 new messages