XmlDataSource: XPath Workaround For Default Namespaces

Having not worked with the XmlDataSource control in ASP.NET 2.0 until this week, I was surprised to learn that there was no way to force it to use namespace-qualified XPath queries, which are critical for querying XML with a default namespace set (either at the root or for some branch of the tree).

PRIMER
XML is a text-based data format that utilizes the concept of tagging data in order to form a tree structure. A simple XML document might look like the following:

<xml>
   <Person name='Jason'>
      <url>http://jasonf-blog.blogspot.com</url>
   </Person>
</xml>

(Listing 1)

XPath is a way of specifying which tagged element, or a collection of elements, that you are interested in. For example, I can query the above XML for the "url" element of the "Person" named "Jason" by using the following:

/xml/Person[@name='Jason']/url

Each slash separates the individual elements that are in the path of the nested data. The square bracket after an element is known as a predicate, and is used to filter the results (i.e., in case there are multiple "Person" elements, this predicate only returns those elements with a "name" attribute containing the value of "Jason").

As XML became more and more popular, developers started merging data obtained from different XML documents into one. This led to tag name conflicts, because one XML document might contain a "Person" tag that has a totally different meaning than another XML document's "Person" tag. The workaround for this situation was to define Namespaces to identify the context of the elements within the XML. Consider the following:

<xml>
   <Person name='Jason' xmlns='WebsiteUserNamespace'>
      <url>http://jasonf-blog.blogspot.com</url>
   </Person>
   <Person name='Jason' xmlns='UsergroupLeadersNamespace'>
      <url>http://www.nwnug.com</url>
   </Person>
</xml>

(Listing 2)

This demonstrates how two nearly identical Person elements can be assigned to different namespaces (implying that they have two different meanings). The first "Person" element (and all of its child elements) belongs to a namespace called "WebsiteUserNamespace", while the second one belongs to "UsergroupLeadersNamespace". Another way to write the same data, but make it a little easier to work with, is as follows:

<xml xmlns:a='WebsiteUserNamespace' xmlns:b='UsergroupLeadersNamespace'>
   <a:Person name='Jason'>
      <a:url>http://jasonf-blog.blogspot.com</a:url>
   </a:Person>
   <b:Person name='Jason'>
      <b:url>http://www.nwnug.com</b:url>
   </b:Person>
</xml>

(Listing 3)

Here, we're actually defining aliases that are used as prefixes for the tag names. In this case, "a" represents the "WebsiteUserNamespace", and "b" represents "UsergroupLeadersNamespace". Notice that the first "Person" element has all of its tags prefixed with "a" while the second "Person" element is prefixed with "b". This is what makes Listing 3 equivalent to Listing 2.

Now, to query for the "url" of the "Person" with a name of "Jason" that belongs to the "UsergroupLeadersNamespace", I would use the following XPath:

/xml/b:Person[@name='Jason']/b:url

The reason why I said that using prefixes is easier to work with has to do with the concept of default namespaces. Notice that the namespace declarations in Listing 2 does not include an alias prefix definition. This makes every unprefixed element from that branch in the tree a member of that namespace. It is common for the entire document to have a default namespace set, meaning that every element within the XML belongs to that namespace.

The problem with unprefixed elements in XML belonging to a namespace is that you cannot construct a XPath query to drill into these elements (because XPath is what requires the prefixes).

The .NET XML parser solves this problem by allowing you to create a XmlNamespaceManager, and defining a prefix at runtime to represent any particular namespace. Then, you can evaluate XPath queries using these custom prefixes that do not exist in the XML document so long as you supply the instance of your XmlNamespaceManager object (i.e., as an optional parameter on a SelectSingleNode(), etc).

Back to the Topic
Now, what I discovered this week was that the XmlDataSource control in ASP.NET allows you to specify a XML document and an XPath to use in order to return a set of nodes (that can then be bound to a TreeView control, etc). But, it did not provide any mechanism to allow the developer to pass in a XmlNamespaceManager. So, if your XML had a default namespace declared, you were pretty much screwed because you could not construct a XPath query.

Searching the internet found these posts:

• Hanselman: Does XmlDataSource.XPath accept namespace qualifications?


• Hanselman: ASP.NET 2.0 XmlDataSource's XPath doesn't support namespaces


• Evjen: Namespaces and the XmlDataSource Server Control

(I gave up on searching at this point because everything seemed to come to the same conclusion)

The closest thing to a valid workaround was Bill Evjen (pronounced like the bottled water, Evian) suggesting that you just transform the XML first using XSLT in order to remove the default namespace (XSLT transformation is another feature of the XmlDataSource control). Then, you can construct a valid XPath query without worrying about prefixes.

There is an alternative solution that does not require the transform, and allows you to still use namespaces if and when you need to. It's kind of a head-slapper for those who know XPath.

Consider the following XPath:

/xml/*[name()='Person' and namespace-uri()='UsergroupLeadersNamespace' and @name='Jason']/*[name()='url']

It is a little more complicated, yes, but allows you to work with the original XML as-is. Here's the magic of how it works (using Listing 2 as a source of data):

The root "xml" element did not have a default namespace defined, so it can remain in the XPath as is (no prefix). However, the "Person" element belonging to the "UsergroupLeadersNamespace" needs a prefix in XPath. Or does it?

Turns out that if I just use "*" as my second step, then that selects all elements that are children of the root "xml" node. I can then create a predicate that utilizes the built-in XPath functions of "name()" and "namespace-uri()" in order to match these to the values that I need to use.

Finally, because my second step matched the namespace-uri to "UsergroupLeadersNamespace", and I know that in the case of Listing 2, all elements below that point belong to the same namespace, I don't have to continue checking the namespace-uri() value in the predicates of subsequent steps (i.e., I can get away with only checking the name() value).

Bottom line:

/xml/*[name()='Person' and namespace-uri()='UsergroupLeadersNamespace' 
and @name='Jason']/*[name()='url' and namespace-uri()='UsergroupLeadersNamespace']

becomes equivalent to being able to use

/xml/b:Person[@name='Jason']/b:url

if you could pass in a XmlNamespaceManager object.



UPDATE 2006-08-14: I just wanted to disclose that after Googling a bit more, I found plenty of references to the XPath method described here for querying namespace-qualified XML (just not in the context of the XmlDataSource). It's still a neat method to keep in mind in case the scenario ever presents itself again.