Semantic equivalence for XmlNode

[AndersAbel]

I'm working with a lot of Xml generation in a library that uses the classical XmlDocument/XmlElement API rather than XDocument/XElement, so I'm thinking about implementing some comparison helpers.

I'll add a new XmlNodeAssertions class containing BeEquivavelentTo(XmlNode) and BeEquivalentTo(XmlNode, string, params object[]).

The comparison will make a semantical comparison that:

• Checks that fully qualified names of elements matches (regardless of what namespace prefixes are used)
• Ignores any namespace declaration attributes.
• Checks that attribute names and values match, regardless of which order they appear in.
• Ignores any whitespace between elements tags.
• Checks text contents of elements.

This is somewhat more lax than the canonical XML standard that requires the namespace prefixes to be the same, but to me two XML docs are equivalent even if they use different ways to express the same namespace.

[dennisdoomen]

That would be awesome. Issue #3 has been discussing this a long time ago, but I never found the time to implement it correctly.

[AndersAbel]

I'll see if I can make it use an XmlReader internally. That way the logic can be reused to solve #3 too as there is an XNode.CreateReader() method.

[dennisdoomen]

👍

If you would honor the contribution guidelines, it would speed up the merge process. 😏

[udlose]

is this issue still open? i have code that i extended based on the work of Eric White (who worked in the xml group on .NET) - https://blogs.msdn.microsoft.com/ericwhite/2009/01/27/equality-semantics-of-linq-to-xml-trees/

All of my work has unit tests

[AndersAbel]

@udlose The basic functionality is in place, I've apparently had three PRs merged for Xml stuff. But there are still more scenarios that could be added. I don't know if @dennisdoomen has kept this issue open because he wants further functionality added or if the issue simply just didn't get closed.

[dennisdoomen]

@AndersAbel did we use the algorithm from that article?

[AndersAbel]

@udlose @dennisdoomen No, I wrote my own algorithm. I read the article and the biggest difference is that the code in the article is based on the assumption that there is an xml schema available. My code is based only on the XML contents.

With the XML Schema available, the code from the article can do some smart tricks such as treating 25 and +25 as equal if the data type is a number, but not if it is a string.

Using normalization also handles some scenarios as equal that I don't think that my code would do, e.g. <node></node> vs <node/>.

If there is a schema available, the normalization approach taken from that code is more powerful. But for the use case I have it wouldn't be usable as I don't have any schema attached and having to bring in a schema for everything would give a lot of extra work.

[dennisdoomen]

Hmm, it looks like the schema is optional. Would be nice to have those additional features for 5.0.

[dennisdoomen]

Any need for this? Anybody fancy working on it?

[AndersAbel]

The original scope I intended with this issue is in place and merged, so closing the issue. The idea with using the schema-compatible code is really another extension and could be added as a new issue (if anyone wants to spend the time on it).