Xpath and Namespace Specification for Xml Documents with an Explicit Default Namespace

XPath and namespace specification for XML documents with an explicit default namespace

Namespace definition without prefix (xmlns="...") is default namespace. In case of XML document having default namespace, the element where default namespace declared and all of it's descendant without prefix and without different default namespace declaration are considered in that aforementioned default namespace.

Therefore, in your case you need to use prefix registered for default namespace at the beginning of all elements in the XPath, for example :

/xmlns:doc//xmlns:b[@omegahat:status='foo']

UPDATE :

Actually I'm not a user of r, but looking at some references on net something like this may work :

getNodeSet(doc, "/ns:doc//ns:b[@omegahat:status='foo']", c(ns="http://something.org"))

Java XPath: Queries with default namespace xmlns

In your Namespace context, bind a prefix of your choice (e.g. df) to the namespace URI in the document

xpath.setNamespaceContext( new NamespaceContext() {
    public String getNamespaceURI(String prefix) {
      switch (prefix) {
        case "df": return "http://xml.sap.com/2002/10/metamodel/webdynpro";
        ...
       }
    });

and then use that prefix in your path expressions to qualify element names e.g. /df:ModelClass/df:ModelClass.Parent/df:Core.Reference[@type = 'Model']/@package.

Using Xpath With Default Namespace in C#

First - you don't need a navigator; SelectNodes / SelectSingleNode should suffice.

You may, however, need a namespace-manager - for example:

XmlElement el = ...; //TODO
XmlNamespaceManager nsmgr = new XmlNamespaceManager(
    el.OwnerDocument.NameTable);
nsmgr.AddNamespace("x", el.OwnerDocument.DocumentElement.NamespaceURI);
var nodes = el.SelectNodes(@"/x:outerelement/x:innerelement", nsmgr);

Xml Namespace breaking my xpath!

I also have the following xPath:

/List/Fields/Field 

When I remove the xmlns from my XML
the xPath works fine. When it's in
there my xPath finds nothing

If you cannot register a namespace binding and cannot use (assuming the registered prefix is "x"):

/x:List/x:Fields/x:Field

then there is another way:

/*[name()='List']/*[name()='Fields']/*[name()='Field']

Why is there no XPath syntax for namespace-qualified nodes?

Not sure what you meant by "as an identifier".

How do we find nodes by their fully qualified names using pure XPath?

In XPath 1.0, by using local-name() and namespace-uri(), e.g.

"*[local-name() = 'foo' and namespace-uri() = 'http://my.org/ns/2.0']"

In XPath 2.0, there is a richer set of functions related to namespaces, e.g. namespace-uri-from-QName(). But I'm not sure they improve on the above for what you want.

XPath in SimpleXML for default namespaces without needing prefixes

From a bit of reading online, this is not restricted to any particular PHP or other library, but to XPath itself - at least in XPath version 1.0

XPath 1.0 does not include any concept of a "default" namespace, so regardless of how the element names appear in the XML source, if they have a namespace bound to them, the selectors for them must be prefixed in basic XPath selectors of the form ns:name. Note that ns is a prefix defined within the XPath processor, not by the document being processed, so has no relationship to how xmlns attributes are used in the XML representation.

See e.g. this "common XSLT mistakes" page, talking about the closely related XSLT 1.0:

To access namespaced elements in XPath, you must define a prefix for their namespace. [...] Unfortunately, XSLT version 1.0 has no concept similar to a default namespace; therefore, you must repeat namespace prefixes again and again.

According to an answer to a similar question, XPath 2.0 does include a notion of "default namespace", and the XSLT page linked above mentions this also in the context of XSLT 2.0.

Unfortunately, all of the built-in XML extensions in PHP are built on top of the libxml2 and libxslt libraries, which support only version 1.0 of XPath and XSLT.

So other than pre-processing the document not to use namespaces, your only option would be to find an XPath 2.0 processor that you could plug in to PHP.

(As an aside, it's worth noting that if you have unprefixed attributes in your XML document, they are not technically in the default namespace, but rather in no namespace at all; see XML Namespaces and Unprefixed Attributes for discussion of this oddity of the Namespace spec.)

how to ignore namespaces with XPath

You can use the local-name() XPath function. Instead of selecting a node like

/path/to/x:somenode

you can select all nodes and filter for the one with the correct local name:

/path/to/*[local-name() = 'somenode']

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

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.

---

Related Topics