Adding query path for map(), filter(), collect(), etc. on tree-like collections?

This is mostly related to updating and deconstructing xml, which I think is pretty ugly compared to the ease of use of xml literals. For me, I mostly just want to drill right down the tree to collect or map specific nodes. Currently you can either decompose the tree top to bottom, working your way down to the nodes you're interested in, use some external transformers, or gather nodes with a XPath-like query. As an alternative, how about add a set of new methods for tree-like collections that can take a query path for the nodes your intereted in mapping/collecting/etc.? For each element in the query path, if the given tree node can do a full structural match against the current path element the search proceeds. The tree nodes that matches the last path element is subsequently mapped by the supplied functions. In the case of map() it yields a complete tree with updated nodes, while collect() for instance yields the requested child nodes.

I'm not sure what the best solution for the query path is, but I've implemented something similar in a custom format I did my own project. In my case I just used a list of the elements of the kind I stored in the tree, and did a structural comparison of the tree elements against the query element, requiring a full match against all properties in the query element. In my case, elements must be able to test for subset containment.

The suggesting isn't too specific but would something like this make it more practical to work with tree-based collections? Finding a good general way of doing queries is probably the biggest obstacle.