Focusing on the part that moved sections should be reported as no difference made me think of https://semanticmerge.com/, which doesn't compare XML-files, but C# and C code. And as it understand those languages it is able to display if code has moved and not changed.

This leads to an alternative approach for this question: Could it be possible to translate the XML into C# classes, and then do a semantic merge on the resulting code?

One possible approach, if this tool is not written already, could be to translate each and every element to classes, and each attribute (and body texts) to a string property within that class. If you want to ignore namespaces, then let your translator remove them in the translation process.

I translated the XML example given as proof of concept and got the following:

class soapenv__Body {
  class mes__GetItem {
    class mes__ItemShape {
      class typ__BaseShape {
          string body="IdOnly";
      }
      class typ__BodyType {
          string body="Textus";
      }
      class typ__AdditionalProperties {
        class typ__FieldURI  {
            string FieldURI="item:Subject";
        }
        class typ__FieldURI  {
            string FieldURI="item:Categories"; 
        }
      }
    }
    class mes__ItemIds {
      class typ__ItemId {
          string Id="AAMYAAA=";
      }
    }
  }
}

Then I switched the mes:ItemIds and mes:ItemShape and changed the text to Textus. Compared the following two files in Semantic Merge and got the following image:

In this image one can see the move, indicated by the M icon, and the change in text indicated by the C icon. Lines indicates where the different parts have moved/changed, and it possible to actually see the differences if they exist.

Note that Semantic Merge even though understanding C# code, isn't to strict on the identical class names of typ__FieldURI, which could be a nice features as XML can contain multiple nodes with the same name.

Summa summarum: Semantic Merge can correctly identify the XML as identical (or not) even though elements move, if you can convert the XML into a C# class structure.

I wrote and released a Windows application that specifically solves the problem of comparing and merging XML files.

Project: Merge can perform two and three way comparisons and merges of any XML file (where two of the files are considered to be independent revisions of a common base file). You can instruct it to identify elements within the input files by attribute values, or the content of child elements, among other things.

It is fully controllable via the command line and can also generate text reports containing the differences between the files.

One solution is to 'split' the file manually before doing a normal diff (diff, kdiff, whatever) by applying

sed -i 's/>/>\n/g' file.xml

to manually insert newlines. Of course, the splitting can be improved to split at full tags, but this solution is a workaround as there seem to exist no standalone solutions.

Jukka's answer did not work for me, but it did point to Canonical XML. Neither --c14n nor --c14n11 sorted the attributes, but i did find the --exc-c14n switch did sort the attributes. --exc-c14n is not listed in the man page, but described on the command line as "W3C exclusive canonical format".

$ xmllint --exc-c14n one.xml > 1.xml
$ xmllint --exc-c14n two.xml > 2.xml
$ diff 1.xml 2.xml

$ xmllint | grep c14
    --c14n : save in W3C canonical format v1.0 (with comments)
    --c14n11 : save in W3C canonical format v1.1 (with comments)
    --exc-c14n : save in W3C exclusive canonical format (with comments)

$ rpm -qf /usr/bin/xmllint
libxml2-2.7.6-14.el6.x86_64
libxml2-2.7.6-14.el6.i686

$ cat /etc/system-release
CentOS release 6.5 (Final)

Warning --exc-c14n strips out the xml header whereas the --c14n prepends the xml header if not there.

c:\WINDOWS\system32\fc.exe <firstfile> <secondfile>

? :)

For what it's worth, I have created a java tool (or kotlin actually) for effecient and configurable canonicalization of xml files.

It will always:

• Sort nodes and attributes by name.
• Remove namespaces (yes - it could - hypothetically - be a problem).
• Prettyprint the result.

In addition you can tell it to:

• Remove a given list of node names - maybe you do not want to know that the value of a piece of metadata - say <RequestReceivedTimestamp> has changed.
• Sort a given list of collections in the context of the parent - maybe you do not care that the order of <Contact> entries in <ListOfFavourites> has changed.

It uses XSLT and does all the above efficiently using chaining.

Limitations

It does support sorting nested lists - sorting innermost lists before outer. But it cannot reliably sort arbitrary levels of recursively nested lists.

If you have such needs you can - after having used this tool - compare the sorted byte arrays of the results. they will be equal if only list sorting issues remain.

Where to get it

You can get it here: XMLNormalize