Jeni's Musings

I came across a few of the issues you mention such as XPath variables and default namespaces on a rather extensive XPath tool home-project of mine.

The main need was to be able to fully test XPath expressions embedded in XSLT just by copying and pasting them into the tools XPath checker without modification. Whilst inserting hidden ‘def:’ prefixes for default namespaces I couldn’t resist colorizing the XPath too once I had a working parser, XPath looks a lot prettier when fully colorized like the tools currently do with XSLT:-)

Other interesting but rather different problems I came across with XPath were related to XPath auto-generation, predicate-aware auto-completion, and an XPath tracer to allow you to step through an expressions, including stepping into predicates.

With auto-completion the issue was with having to deal with numerous un-closed nested/non-nested predicates etc. Many of the problems here are similar to those encountered with an XPath tracer.

On XPath auto-generation from an XML source, its fairly routine if the root node is the context node, but I’m going to have to generate XPath up or down the tree from the set context node and I’m not quite sure how to do this yet in a useful way.

With XPath variables I use grouped hashtables and store/load them in an XML serialized object - the next step is to write the XSLT to map the XML to an XSLT source file, so as to auto-populate the variables.

Namespaces with XPath will probably never be ideal. The most recent XML recommendation restricts (I think) some of the more eccentric ways that namespaces can be declared. This may help an XPath solution that deals with overriding of locally declared namespaces, but I haven’t investigated this yet.

Back to the main theme, XPath is now used so pervasively that, though there may be more elegant solutions, I don’t see it being sidelined any time soon, at least, I hope it won’t be, because I quite like it now.

Phil Fearon