As a developer of an XPath tool I would of course agree. It is however disappointing that the XML community doesn't do more to help promote the use and understanding of XPath.

Many of the blogs and articles I've seen recently that reference XPath have been unfavourable, unhelpful and downright misleading comparisons with LINQ to XML.

It would be good to see XPath, especially in 2.0 form, put out there a bit more.

Agreed - I can understand the confusion, to some extent: XPath 2.0 is *not* synonymous with XSLT 2.0 or XQuery 1.0, which seems to be a pretty common misconception, any more than SQL is synonymous with Oracle or mySQL. The chicken and egg problem remains - you have to use it to get it, you have to get it to use it.

Anyone who writes programs should write unit tests for them. The best way to test XML is to query into a DOM, looking for specific details, with XPath.

That's why assert_xpath is so useful, and hence it's why anyone using XML for anything should learn XPath

@Phil,

>> It would be good to see XPath, especially in 2.0 form, put out there a bit more.

Oh, I absolutely agree! There is a somewhat dormant OSS .NET XPath 2.0 implementation sitting out there in the Mono Project repository that got set aside when MSFT dropped XQuery support for stand alone XML files.[1] Would be *great* to see that picked up by someone and finished up (as far as I am remembering correctly, there's still a bit to finish up to bring it in compliance with the final XPath 2.0 spec, though it's certainly within a few weeks worth of hacking reach. And there's support for XQuery as well, though it would require quite a bit more to finish that up, as far as I can tell.)

And Micah Dubinko has his WebPath project which forms the foundation of a Python-based XPath 2.0 engine. [2]

Of course, I'm still fairly confident that MSFT will eventually bring native support for both XPath 2.0 and XQuery 1.0, primarily because the support already exists (at least at it relates to the November 2005 spec) -- in fact, while I have purposely avoided opening up the Microsoft internal classes within Reflector to verify, I've long suspected that buried inside somewhere exists the original XPath 2.0 and XQuery implementation. Regardless, its not something that would be all that hard to bring back into existence, and when the time is right and the resources available, my guess is the MSFT will get themselves current with all of the W3C XML specifications that they currently provide support for in their 1.0 form, adding XQuery to the mix, again, because it already exists -- somewhere ;-).

[1] http://www.mono-project.com/XML#Mono.Xml.Ext
[2] http://www.oreillynet.com/xml/blog/2008/01/micah_dubinkowebpath_bsdlicens.html

>> Agreed - I can understand the confusion, to some extent: XPath 2.0 is *not* synonymous with XSLT 2.0 or XQuery 1.0, which seems to be a pretty common misconception, any more than SQL is synonymous with Oracle or mySQL.

It's funny how often I forget to use XPathNavigator in standalone form, choosing to write a ridiculously simple XSLT to perform a filtering operation that can easily be done with XPath alone.

>> The chicken and egg problem remains - you have to use it to get it, you have to get it to use it.

There's always baptism by lack of other options, of course, but for better or worse, there are *plenty* of other options out there these days. None of them as clear, concise, and powerful as XPath 2.0, but options none-the-less.

@Phlip,

>> and hence it's why anyone using XML for anything should learn XPath

Absolutely!