XPath is a family of small query languages for XML: they have a simple data model and syntactically were based on directory paths: so to find the attribute id of the parent of a chapter element which has a title "XPath needs virtual axes", you might use an XPath like chapter[title='XPath needs virtual axes']/../attribute:id in XSLT.
There have been two versions of XPath, 1.0 and 2.0 so far. Each has several standard dialects: the XPath in XSLT for example adds some functions that it needs. XPath 1.0 was excessively minimal, which in the standards world is perhaps more an accomplishment than a shortcoming; but this minimality almost guaranteed that another version would be needed as experience accumulated. A grassroots effort created an extended version of XPath 1.0 called EXSLT; recently Florent Georges has been investigating an EXSLT2.
I really like XPath2. I would never recommend anyone start with XPath1, unless you were doing very basic transformations with no text processing or data formatting.
But the niggle I have with XPath2 is that it is less XPath-y than XPath1. It does not significantly improve the central syntactical feature of XPaths: the location steps. (The only improvement that springs to mind is that XPath2 did improve the use of parentheses in location steps.) Instead, XPath2 provided much more conventional features like a for iterator. I think these significantly decrease the comprehensibility of an XPath, are anonymous and therefore require may comments to explain them, and fracture the line. To an extent, once you start to use nested syntaxes and iterators, why both using XPath at all?
XSLT2 provides a syntax for defining functions that can be used in XPath 2, which is a good advance, since more can be done inside XPath 2 that would otherwise have to use XSLT syntax, such as call-template.
I have been involved in numerous projects over the years where XPath (even XPath2) has been maddeningly almost good enough. These all involve using XPath for real XML markup and specification languages (as distinct from simple data dumps): XSD, RELAX NG, Schematron, DSRL, OOXML, ODF and so on, involving thousands of lines of code.
But it was working playing with an SVG input that really crystallized my thinking. In all these systems, they have various kinds of inclusions and reference systems. If you look at SVG, OOXML or ODF, the issue of What property applies to this element? can involve looking up a remote tree of multiple cascaded stylesheets, attributes of ancestors (or their children), or elaborate defaults. (And finding the units of those values may also involve searches.) The value of XPath is its linearity and straightforward terseness: but these kinds of common documents defeat XPath.
What became apparent to me was that for this kind of document, the XPathy way to do things (i.e. the way which would take advantage of XPath's syntax, which is so terse and clear for many kinds of navigation) would be to be able to define virtual axes.
Michael Kay has also mentioned the same idea: he points out (err somewhere, on his blog?) that all that would be needed would be for XSLT function definitions to operate such that functions which take a node sequence and return a node sequence can be used as axes.
Now the difference may be cosmetic: instead of something like
you would have something like
But it does two things: first, it does not break the analogy of the path or location step. You don't have two syntaxes, you have one. And second, compared to an explicit for statement, it provides a name, leading to clearer specification of the intent of the axis. We don't have to keep track of two or three places and jerk our heads and poor brains around: the location path reads linearly.
So I certainly would support this (i.e. virtual axes) for a future or update version of XPath. Syntax matters. XPath needs to be more XPathy, not further diluted. Look at the syntactical sugar in Scala or Ruby for example of how small syntactical innovations allows clearer or stronger expression of the idea of the code (leading to the so-called DSLs.)
[UPDATE] Dimitri (who is has been brilliantly active in the XSLT community, let me say) has put his comment below up as a blog entry. He adds Also, consider that the axes in XPath have been useful so far mainly because there are just a few of them. Imagine having to deal with zillions of axes and struggling to remember what they mean. And if everyone can introduce their own axes, then why bother with them at all?
With respect, I think this is ridiculous. People are not confused by zillions of functions, why should they be confused by zillions of axes? Just like a functions, you understand what they are about by giving them clear names. The value of axes is not that they are limited, but that they provide a simplified syntax for various compound functions.
The use of functions as location steps breaks this, though not to the extent that I think the syntax is bad. (The only thing I can see against virtual axes is that axis spelling errors could only be caught at compile or run time, not at edit time. I don't think it is a big deal.)
(I cannot comment on Dimitri's blog, since I don't have any of the kinds of IDs it allows.)