One of the reasons I even thought about writing a native XPath Generator for Mozilla-based applications is a need to take a XPath for a DOM tree and translate it into a path for a DOM Inspector-like node tree. Unfortunately, as my mind has just now started wandering back towards my Verbosio application (for which I would use this XUL tree), I realized I had completely forgotten to include any functionality in the IDL or in the implementation for creating a XPath that would be friendly to this.
Specifically, I wanted a XPath that looks like: /node()[5]/node()[7]/node()[11]. I didn't think about that when writing the extension, though. Fortunately, I had a lot of foresight in allowing for extensibility. So, pending reviews to land the xpathgen code (which I don't expect right away), I'll submit a new bug to to "GET_CHILD_INDEXES_ONLY".
I might argue that I own the spec and I can do what I want there, but I don't buy that. I'm doing this for the community, so even when I suggest a new idea for the spec, I make sure to run it by someone else for approval.
UPDATE: Or maybe not. Collecting adjacent text & cdata nodes under XPath makes it not so useful.
Posted by WeirdAl at March 4, 2006 10:52 AMI wonder if the flags should be
- include localname
- include namespace
- include childpos
- include attributes
- include namespaced-attributes.
Not sure how that goes together with what you have, I must admit that I didn't manage to look at the bug lately.
(From Alex: I thought about that initially, but the more flexible includeAttributeNS scheme seemed best. Again, I'm welcoming ideas for improvement that are practical.)
Posted by: Axel Hecht at March 5, 2006 12:59 PM