I ran into an issue that stumped me for a while and wanted to write about it so maybe others won't be slowed down as long as I. I was writing a XCollectionResolver and XResultsResolver that connected to the database. For some reason, while these resolvers returned data that looked valid, they couldn't be navigated by XPath 2.0. I saw things like this is XQuery:
let $a := trace($domainSpammers/spammers/spammer/email, "email =")
Traced nothing, while
let $a := trace(node-name($domainSpammers/*/*/*), "threestars = ")
Traced email, uri, and name. I even put domainSpammers into the output of the XQuery and could see the spammers/spammer/email tree:
<spammers xmlns="http://www.w3.org/1999/xhtml" xmlns:xs="http://www.w3.org/2001/XMLSchema">
I looked at this for a few hours. Luckily one of my team members saw the issue. You can see by the title of this post and the above xml, the issue was the elements are in the XHTML namespace.
It turns out I was writing to the document from XSLT 2.0 using the new feature of multiple result documents. While I wanted my browser returned page to be in the default namespace of XHTML, I didn't want the data written to the database to be in the XHTML namespace. However, since I didn't clarify this, it mistakenly was written to that namespace.
Next time, and maybe this will help you, I'll add namespace-uri() to my debugging arsenal:
let $a := trace(
namespace-uri($domainSpammers/*/*/*)), "threestars = ")
Which would clearly have shown that email was in the XHTML space:
a = email http://www.w3.org/1999/xhtml;
Which would have saved me a few hours of pulling my hair out.