This finding attempts to provide an answer for the question “when are two XML chunks equal?” Taken narrowly, a chunk of XML is an information item (a document, element, attribute, etc.). Taken broadly, it is a set or sequence of information items (a set of documents, a sequence of elements, a heterogeneous sequence of items, etc.).

Many applications will require their own special-purpose algorithms, but this finding provides one general solution that attempts to balance utility and complexity.

Different applications can have very different notions of what constitutes identity or equality:

A digital signature application may need a canonical, bit-for-bit identical lexical representation of both the data and the markup.

A language runtime system may need to know that two variables refer to the same data structure in memory.

A semantic inference application may need to know that two representations have the same URI.

A message passing application may need to know if two distinct messages are “the same,” if they are structurally equivalent.

It is the latter class of equality that this finding attempts to address. Given two distinct XML structures, can we decide if they convey “the same information.”

We describe this equality in terms of the .

We define chunk equality in terms of the . Similar definitions could be defined on top of the Post-Schema Validation Infoset (PSVI), the data model, or the . We choose the infoset because it is a common abstraction for XML specifications.

A few general notes about how the comparisons are performed:

Information items of different types (elements and attributes or comments and processing instructions) are never the same.

Ordered lists (such as the [children] property) are compared pairwise and in order. In other words, two ordered lists "A" and "B" are the same if and only if the first item if "A" is the same as the first item of "B", the second item of "A" is the same as the second item of "B", etc. It follows that they can only be the same if they are the same length.

Unordered lists (such as the [attributes] property) are compared pairwise but without respect to order. In other words, two unordered lists "A" and "B" are the same if and only if there exists a set of pairs of items, one from each list, such that the two items in each pair are equal and no item from "A" or "B" appears in more than one pair. It follows that they can only be the same if they are the same length.

XML Base. If the infosets being compared were constructed by an application that claims conformance to the XML Base recommendation, then the xml:base attribute is excluded from attribute comparisons.

In this specification, the base URI is not considered significant.

Natural Language. The xml:lang attribute is not treated specially in the Infoset but is intended to have a scoped effect much like the base URI. This intention is made explicit in this specification.

If the infosets being compared were constructed by an application that provides application semantics for xml:lang, then the application must be able to determine whether or not two elements or attributes have the same language.

If the infosets being compared were constructed by an application that does not provide special semantics for xml:lang, then two elements or attributes have the same language if they have the same inherited value for xml:lang.

The inherited value for xml:lang is the value of xml:lang on the element in question or the value from the closest ancestor. In XPath terms: (ancestor-or-self::*/@xml:lang)[last()]

Languages are compared case insensitively.

XML Space. This specification does not extend any special status to the xml:space attribute, nor does it treat whitespace marked as [element content whitespace] in any special way.

When two information items are compared:

Properties with the value "no value" are equal.

Properties with the value "unknown" are not equal.

The algorithm described in is very conservative. It could be made more permissive with the addition of a few parameters. For example, parameters could adjust the algorithm to do any or all of the following:

Ignore processing instructions.

Ignore comments.

Ignore the document type declaration.

Even if the algorithm remains conservative, applications can influence the results by choosing how the infoset is constructed. There is no single, normative way to construct an infoset.