"Diff cleanliness" when removing an element that has siblings with the same name

[keith-hall]

I really like how this library isn't too bothered about the order of different XML elements, i.e. diffing the following:

<root>
    <example1 id="example1" />
    <example2 id="example2" />
    <example3 id="example3" />
    <example4 id="example4" />
</root>

and

<root>
    <example3 id="example3" />
    <example1 id="example1" />
    <example4 id="example4" />
</root>

results in:

= Element "root"
...- Element "example2" "id"="example2"

However, I've noticed that the diff shown when removing an element that has siblings with the same name isn't as "clean" i.e. (just removing the numbers from the element names compared to the sample above):

<root>
    <example id="example1" />
    <example id="example2" />
    <example id="example3" />
    <example id="example4" />
</root>

vs

<root>
    <example id="example3" />
    <example id="example1" />
    <example id="example4" />
</root>

which results in:

= Element "root"
...= Element "example" "id"="example3"
......- Attribute: "id" with value: "example1"
......+ Attribute: "id" with value: "example3"
...= Element "example" "id"="example1"
......- Attribute: "id" with value: "example2"
......+ Attribute: "id" with value: "example1"
...= Element "example" "id"="example4"
......- Attribute: "id" with value: "example3"
......+ Attribute: "id" with value: "example4"
...- Element "example" "id"="example4"

It'd be great if we could add the ability to produce a diff like the following instead:

= Element "root"
...- Element "example" "id"="example2"

In my opinion it makes it much clearer to see what actually changed. I imagine that if we want to keep the old behavior, we could add a parameter to the XmlComparer constructor which would define which comparison algorithm to use, and it could have a default value so as not to affect any existing applications using this library.

---

I think it's this code and/or this code that would need to change.
I realize that it would probably be useful if we can define what makes an element "the same". When the elements have no children, it is fairly simple - an element with the same name and exact same attributes can be considered the same.
In fact, rather than deciding on complicated logic for the other cases (elements with children, more/less attributes/different values etc.), maybe the simplest method to produce the "cleanest" diffs would be to find the element with the same name that has the least differences. i.e. for each element in the destination document, find all elements with the same name in the source document and order them by the count of differences between the two, and take the one with the least differences. If all the destination elements have already found matches in the source document, those remaining unmatched source elements can be considered removed. Hopefully this won't affect performance too much, as I like how fast this library currently is.
Maybe I'm over-engineering this in my head, but it may even make sense to add weighting so that changes to attributes would score differently to changes to children (or text content), so that something like:

<root>
  <example>Hello World!</example>
  <example attr="value" />
</root>

vs

<root>
  <example attr="foobar" />
  <example>hello world.</example>
</root>

would produce a more "natural" diff - i.e. the Hello World! text becomes hello world. and the attr value becomes foobar, i.e. one "operation", as opposed to 1. removing the attribute 2. adding the text (or the opposite) or 1. removing the attribute. 2. adding the same attribute with a different value being 2 operations.

[ashapkin]

Thanks, Keith!

In my opinion it makes it much clearer to see what actually changed. I imagine that if we want to keep the old behavior, we could add a parameter to the XmlComparer constructor which would define which comparison algorithm to use, and it could have a default value so as not to affect any existing applications using this library

Telling the truth I was thinking about this too. Cant remember why I decided to ignore this case. Probably case of logic complication.

I realize that it would probably be useful if we can define what makes an element "the same"

Yep, this is a challenge. Since without XDT we can not really think in term of "ordering". But anyway if both of us were thinking about this, It's a good reason for implementation.

In fact, rather than deciding on complicated logic for the other cases (elements with children, more/less attributes/different values etc.), maybe the simplest method to produce the "cleanest" diffs would be to find the element with the same name that has the least differences. i.e. for each element in the destination document, find all elements with the same name in the source document and order them by the count of differences between the two, and take the one with the least differences. If all the destination elements have already found matches in the source document, those remaining unmatched source elements can be considered removed. Hopefully this won't affect performance too much, as I like how fast this library currently is.

Sounds interesting. I need to investigate this during my free time.

Also I would like to point some thoughts about this lib and warn about using it in prod :D The initial goal was to "keep it simple" and to solve a concrete issue I have faced with. There are a lot of similar libraries with much more robust and flexible code. This solution is not a swizz-knife, it have just a several files and a simple output. That's why I've preferred to reinvent a small wheel :)
Probably we can take a look at this tool.

In overall, my improvement suggestions:

• we are looking only at atts/value/node changes, but not at CDATA for example (actually this is not a case in *.config files, but anyway)
• I'm pretty sure that some edge cases are missing during the comparision :)
• execution time/visitors could be improved
• siblings handling (as you pointed) is important for *.configs
• probably converting to nuget package or whatever
• etc

[keith-hall]

I took a look at the tool you linked, and found it hard to get the source code for the actual diff algorithm, but then I discovered that it is used in XML Notepad and figured I'd link it here so you don't have the same trouble and waste time :)

From my perspective, I'm not too bothered if it doesn't show differences when a PCDATA node is changed to a CDATA node or vice versa, because from a DOM perspective, they are the same. However, I can see that there might be some circumstances where it would be useful to see when/where it changes. XML Notepad seems to show this when you go to the View menu -> Compare XML Files... so the algorithm they are using must detect it.

A NuGet package for this would sure be cool, I was going to ask for that after we convert it to .NET Core 2.0 ;) it'd also help your little project to reach a bigger audience, assuming you want that as it could come with a side effect of more people logging issues, but I guess they could help find any edge cases for us ;)