XQuery Node Identity: Equal Text Can Be Different Nodes

I use XQuery node identity when I need to know whether two paths select the same source node. Equal text doesn’t establish that identity. Repeated values can belong to separate sibling elements with different positions and roles.

Keep the repeated values in one document

The fixed XML contains three Item elements. The first two both contain blue, while the third contains green. Their simple content makes it easy to separate source-node identity from value comparison.

I keep all comparisons inside methods on the same Doc value. Each operand selects one Item using a parenthesized path and a positional predicate. That singleton selection keeps the comparison question precise. The example doesn’t compare detached text strings and then infer where they originally appeared.

WITH Source AS
(
 SELECT CAST(N'<Root><Item>blue</Item><Item>blue</Item><Item>green</Item></Root>' AS xml) AS Doc
)
SELECT Doc.value('(/Root/Item[1]/text())[1]','nvarchar(20)') AS FirstText,
       Doc.value('(/Root/Item[2]/text())[1]','nvarchar(20)') AS SecondText,
       Doc.value('(/Root/Item[3]/text())[1]','nvarchar(20)') AS ThirdText,
       Doc.value('if ((/Root/Item)[1] is (/Root/Item)[1]) then 1 else 0','int') AS FirstIsFirst,
       Doc.value('if ((/Root/Item)[1] is (/Root/Item)[2]) then 1 else 0','int') AS FirstIsSecond,
       Doc.value('if ((/Root/Item)[1] = (/Root/Item)[2]) then 1 else 0','int') AS FirstTextEqualsSecond,
       Doc.value('if ((/Root/Item)[1] is (/Root/Item)[3]) then 1 else 0','int') AS FirstIsThird,
       Doc.value('if ((/Root/Item)[1] = (/Root/Item)[3]) then 1 else 0','int') AS FirstTextEqualsThird
FROM Source;

Compare a node with itself

FirstIsFirst compares the first selected Item with the same selected Item. Its expected result is one. The is operator asks whether those operands represent the same node in the source document.

I display one or zero through an XQuery conditional for a straightforward SQL integer output. That display convention doesn’t change what the IS operator compares. The result is an identity decision rather than a count. A repeated selection of one node remains one node even when its content is ordinary text.

Compare different nodes with equal text

FirstIsSecond expects zero, because the first and second Items are distinct source nodes. FirstTextEqualsSecond expects one, because their atomized values are equal. Both answers are correct for the same pair of elements.

I’d keep those columns together when explaining a deduplication or path-selection requirement. A text match can find repeated content without identifying one original occurrence. A consumer needing source identity must preserve that context. Extracting only blue from both elements loses the difference demonstrated by this row.

Use the third element as a contrast

The third Item contains green. FirstIsThird and FirstTextEqualsThird both expect zero. That case differs from the equal-text sibling comparison, where only identity was false.

I’d retain the visible text columns beside the comparison results. Otherwise a zero could be explained without checking which kind of difference occurred. The complete tuple shows both situations clearly. Different text can accompany different nodes, but different nodes don’t require different text.

Keep path cardinality deliberate

Node identity compares selected nodes, so the example gives each operand a singleton path. A broad path returning every Item would ask another question and could violate the comparison’s required operand shape.

I’d review cardinality before adapting the expression to optional or repeated application elements. This fixed document contains every selected position. It doesn’t invent a missing-node policy for a larger schema. Choose that policy separately and test the actual paths before relying on an identity result.

Preserve the distinction at the interface

The query reads a single inline XML value and makes no writes. Its eight output columns include all texts and all comparison results. The expected tuple is based on that exact source document.

I’d name identity and value fields distinctly in a report or API. A generic Equal flag can hide which relationship was checked. Keeping the names precise helps a later reader understand the decision. Neither result alone establishes a business key or authorizes merging records with repeated content.

Name the comparison you need, and the answer will match your question.

Equal text is not the same node, it is two nodes that happen to match.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.