interesting. partly, you are right. and this is the reason why we decided to not let the user enter the xpath directly. instead, we created an xpath-like syntax which is then mapped internally to a real xpath. /node[name()=_usr_]/node[name()=_bin_]/node[name()=_find_] can be avoided this way, or even better, we don’t even use the xml element name for carrying the file name, so we don’t have problems with characters which are nor allowed in xml names. however, characters whcih are not allowed in *xml* still are a problem…

so why could it be useful? i think that as a productivity tool, it could be quite useful for sysadms and other power users, but we also never got around to implementing enough adaptors to make it really interesting…

I do agree that any reasonable implementation should support paths like /usr/bin/find. Mine supports too.

The problem with codes \001, \002 etc also can be workarounded. Most systems check for bad symbols only when parsing XML, and don’t check when manipulating XML in memory.

By mentioning Ant and your XSLT example, you’ve convinced me that practical use cases for XPath over filesystem do exist. Nice.

In short, each issue in my list isn’t a showstopper and can be workarounded. But I still insist that XPath over filesystem has failed, at least for my goals. The problem, which I failed to formulate in the original post, is the leaky abstraction. (For several minutes, I was distracted by re-reading “The Law of Leaky Abstractions“.) All that small problem, taken all together, lead to the leaky abstraction.

Initially, my XPath over filesystem was developed as a reference implementation for deploying my XML Virtual Machine. Unfortunately, the leakage caused bothering about lots of unrelated details instead of actual deploying.

And I still have no good practical idea for a reference implementation.

The fourth point is somewhat unsettling ; I simply wouldn’t use a system that would write paths like this : /node[name()=’usr’]/node[name()=’bin’]/node[name()=’find’] ; my own implementation do really understand paths like this : /usr/bin/find

The fifth point is a real problem ; although files with codes like “01″, “02″ can’t be named in XPath expressions, they can be handled anyway (”//*”). I have encountered that issue with legal XML characters that are illegal in XML names, and for such a case I use the alternative syntax *[name()=’my file’] (as “my file” contains a white space) ; codes like “01″, “02″ could be escaped ; fortunately, these cases occur rarely.

Sixth, I agree that using XPath on the command line to handle files won’t help much more than the usefull “find”-like commands. However, using it on another environment may help ; for example, instead of using numerous elements that define file sets in Ant (<fileset>, <dirset>, <include>, <exclude> etc and other ugly things like “**/*.jar”) we could consider XPath expression instead (this is an exercice that I have submitted to my students).

To conclude, my own experience on using XPath to walk through file systems is a success, certainly because I used it with a real XML-based system. When I have a set of XML files to transform with XSLT, I write it simply like this :

<xcl:for-each name="file"
  select="{ io:file('/path/to/dir')//*[@io:is-file] }">
     <xcl:transform source="{ $file }"
         output="{ substring-before( $file/@io:path , '.xml' ) }.html"
         stylesheet="/path/to/stylesheet.xslt"/>
</xcl:for-each>

This is an appropriate solution on an appropriate system.
http://reflex.gforge.inria.fr/