That sounds like a good idea. The DOM working group has been struggling with this for awhile, though, and you should at least be aware of the problems. Not being hindered by the various non-technical constraints that the W3C faces/imposes, perhaps we can do better here.

The basic problems have been:- A disagreement whether to do something minimal (a la Microsoft selectNodes) or a fully-functional XPath API. Not surprisingly, the minimal solution falls afoul of namespaces in all sorts of nasty ways; MS has some workarounds, but they are not terribly elegant. A fully functional solution requires some mapping between the XPath and DOM conceptions of a namespace declaration.

- The wretched inconsistency between the DOM data model and the XPath data model. DOM "trees" can have CDATA nodes, adjacent Text nodes, entity reference nodes (and maybe some other rot) that is transparent to XPath. So, an XPath expression can point at something that is not neatly aligned on DOM Node boundaries ... so what should a NodeList or NodeIterator returned by an XPath expression do?

- The equally wretched matter (I'm sure I will suffer painfully in the Hereafter for ever agreeing with this) of live NodeLists. The obvious thing for something like selectNodes to return would be a NodeList, but keeping this in synch with the XPath expression as the underlying DOM tree is edited is non-trivial. NodeIterators are probably a better idea, but they are less familiar and less widely supported, and still have some "liveness" semantics that might be problematic here ... not sure.

- There may be more, and the W3C DOM WG may have discussed this in more depth at the recent face to face meeting that I missed. Any W3C members participating here should probably read through the DOM archives to make sure that any relevant issues are reiterated for the larger group.

Anyway, I wish you well, and will help however I can. Maybe some fresh ideas can help here!