How does XPath deal with attributes which have conflicting expanded names?

Given the following document ...

<?xml version="1.1"?>
<doc xmlns="https://www.example.com" xmlns:n1="https://www.example.com"
     a="1"
     n1:a="2"/>

... (Q1) What is the canonical result of this xpath 3.1 expression ..

n2:doc/@n2:a

... if the context node is the document, and a namespace binding xmlns:n2="https://www.example.com" is attached to the xpath processor?

(Q2) What about expression ...

doc/@a

... with a namespace binding of xmlns="https://www.example.com" on the xpath processor?

What I've tried

I've had inconsistent results with various different xpath implementations, suggesting that this is a bit of a grey area in the XPath spec. I've even experienced a return of a sequence of two nodes, which at first blush, is an unexpected result.

References:

Solution

The attributes in your example are not conflicting, because an unprefixed attribute is in no namespace, not in the default namespace of the containing element. @n2:a will select the namespaced attribute if prefix n2 is bound to the namespace https://www.example.com; @a will always select the no-namespace attribute. (If you see different behaviour from an implementation, then it's wrong.)

What if the attributes actually were conflicting, for example if you had an element

    <doc xmlns:n0="https://www.example.com" 
         xmlns:n1="https://www.example.com" 
         n0:a="1" 
         n1:a="2"/>

and put this through a non-namespace-aware XML parser?

The answer is that the input violates the constraints in the XDM specification, which defines the data model for XPath. Some quotes from XDM 3.1:

§2.7: As with other consistency constraints described in this data model, it is a precondition that these constraints are satisfied; the specifications do not speculate on what happens if they are not.

§3: The data model supports well-formed XML documents conforming to [Namespaces in XML] or [Namespaces in XML 1.1].

§6.2.1: Element Nodes must satisfy the following constraints. (2) The Attribute Nodes of an element must have distinct xs:QNames.

So the answer is, if your system allows you to execute XPath expressions on documents that aren't namespace-well-formed (which might well be the case, e.g/ some DOM implementations are not namespace-aware by default), then the XPath specification explicitly says that all bets are off.