XML Comparison Rules

XML comparison rules determine how parsed element names, attributes, text, and repeated children are matched. Choose them from the meaning of the document, not from which settings produce the fewest differences.

What Data Compare examines

Data Compare parses each document into a tree-like value and compares:

• Elements, including their names, nested children, and text content;
• Attributes, independently from the element’s text and child elements;
• Text, including text supplied through CDATA sections.

Attribute order and indentation between elements do not create structural differences. Element names and values are case-sensitive by default. Use Git Diff on the result page when the exact original source formatting matters.

For example, these documents are structurally equal in Data Compare:

<service name="billing" enabled="true">Ready</service>

<service
  enabled="true"
  name="billing"
>Ready</service>

A changed attribute value, changed text, missing child, or renamed element is still a semantic difference.

Match repeated elements

Repeated child elements become ordered collections during parsing. The Array Comparison setting in Settings controls their alignment even though the values are XML elements rather than JSON arrays.

Consider this Base input:

<regions>
  <region>us-east</region>
  <region>eu-west</region>
  <region>ap-south</region>
</regions>

And this Contrast input:

<regions>
  <region>us-east</region>
  <region>ap-south</region>
  <region>eu-west</region>
</regions>

By Index

By Index is the default. It compares each repeated element with the element at the same position. In the example, positions 1 and 2 both change because eu-west and ap-south exchange places.

Use By Index when positions have stable meaning, such as fixed configuration slots or ordered snapshots. An insertion near the beginning can make many later elements appear changed because their positions shift.

LCS

LCS uses the Longest Common Subsequence to align equal elements while preserving order. It is useful when a mostly ordered sequence gains or loses entries and you want those insertions and deletions aligned to unchanged siblings.

LCS remains order-sensitive. A move is represented through deletion and insertion rather than as a special move operation, and an insertion can have more than one valid alignment when values repeat.

Unordered

Unordered ignores sibling order and matches values as a multiset. In the example, all three regions have the same values and occurrence counts, so Unordered reports them as equal.

Duplicate counts still matter. These documents are not equal under Unordered because Base contains two admin entries and Contrast contains one:

<!-- Base -->
<roles><role>admin</role><role>admin</role><role>editor</role></roles>

<!-- Contrast -->
<roles><role>editor</role><role>admin</role></roles>

Use Unordered for collections such as tags or permissions only when order is irrelevant. It is not a set comparison and does not discard duplicates.

Name and value case options

XML has two case switches and no separate numeric-string option.

Ignore Element/Attribute Name Case

This option applies to element and attribute names. With it enabled, these names can match:

<Service Status="ACTIVE" />

<service status="ACTIVE" />

Leave it off when differently cased names are distinct in your XML vocabulary. Enabling it can intentionally suppress both element-name and attribute-name differences.

Ignore Value Case

This option applies to text and attribute values. With it enabled, ACTIVE and active compare as equal:

<service status="ACTIVE">Ready</service>

<service status="active">ready</service>

Do not enable it for case-sensitive identifiers, tokens, or user content. It changes value comparison, not element or attribute name matching.

Parser normalization and limitations

Comments are ignored

Changing or removing an XML comment does not create a Data Compare difference. The comment remains visible to Git Diff because that view uses the original input text.

CDATA is text

CDATA sections contribute text values rather than forming a separate node category. These values compare as equal:

<description>Primary billing</description>

<description><![CDATA[Primary billing]]></description>

Changing the characters inside CDATA changes the text value. Data Compare may render the normalized value without preserving the original CDATA notation.

Numeric-looking values become numbers

The parser converts numeric-looking element text and attribute values to numbers. Consequently, 1 and 1.0, or 2.5 and 2.50, can compare as equal even though their source spelling differs:

<limit retries="3">1.0</limit>

<limit retries="3.0">1</limit>

This conversion is automatic. There is no Numeric String Equals Number switch for XML. Use Git Diff to inspect numeric spelling changes that Data Compare treats as equal.

Namespace prefixes are not resolved to a canonical URI

The parser keeps namespace prefixes in element and attribute names; it does not expand names to canonical namespace URIs before comparison. Documents that use different prefixes for the same namespace can therefore report name differences. Treat prefix changes as potentially significant and review them alongside namespace declaration attributes.

For example, soap:Envelope and env:Envelope are not normalized to the same expanded name merely because their declarations identify the same URI.

Data Compare, normalized output, and Git Diff

Data Compare uses the parsed values and all selected rules. Its editors render XML reconstructed from those values, so source comments, original indentation, CDATA notation, and numeric spelling are not guaranteed to survive in the displayed result.

Git Diff instead compares the original Base and Contrast text line by line. It can show formatting, comments, attribute layout, or value spelling even when Data Compare reports Same. Conversely, semantic options can suppress a structural difference without changing the original-text diff.

The result page exposes semantic Settings in Data Compare. Changing a rule recalculates Data Compare; Git Diff remains a read-only view of the original input text.

Troubleshooting

Reordered siblings produce differences. By Index and LCS preserve order. Select Unordered only if order has no meaning, and check duplicate occurrence counts.

One insertion shifts many values. By Index aligns positions. Try LCS for an ordered sequence with insertions or deletions.

Different namespace prefixes produce unexpected differences. The comparison does not canonicalize prefixes by namespace URI. Normalize prefixes before comparing only if your workflow establishes that the prefixes are interchangeable.

A comment or numeric-spelling edit appears only in Git Diff. This is expected: Data Compare ignores comments and converts numeric-looking values, while Git Diff compares original text.

A case difference disappears. Check whether name-case or value-case ignoring is enabled. Return to Data Compare to review the active settings.

Start with the XML Getting Started guide for a complete Base-to-Contrast example, result navigation, URL loading, sharing, and privacy guidance.