On Fri, 2012-12-14 at 17:04 +0100, Hussein Shafie wrote:
> > Command xpathSearch evaluates specified XPath expression in the context > of selected node. Therefore if there is no selected node, xpathSearch > cannot be executed. Unless of course, you pass it option [implicitNode] > or option [implicitElement]. Both options should work fine because your > expression starts with '//'. > > In summary: > > xpathSearch [implicitNode] //*[@Name = 'nx'] > > should work fine. > Thanks, see my following e-mail, indeed it does. However, there is a more fundamental issue with element search (and maybe a track for improvement) that we do not know how to tackle easily with commands. I'll try to summarize it: + Usually we want to trace all elements matching a given search criteria, in our case @Name = 'myname'. Getting the node-set is pretty obvious with one simple Xpath statement (e.g. from the current/implicit element: "self-or-descendant::*[@Name = 'myname']" + But the hierarchical tree of nodes may be quite complicated, so starting from the last match to find the next one is not always a very good option, expecially because all the node-sets have already been identified at once. + Having just a way to move up and down the tree of found matches would be much easier. In short, what would really be efficient is to have the same search behavior as for text nodes from auser points of view: 1. You search for an node-set by issuing either a simple or an advanced Xpath query 2. One the node-set has been found, the next/previous match simply move up and down the matching node-set Otherwise, the "search next" might just be very difficult, or impossible (?) to write. We do not know if it makes sense to implement this in XXE, but we might implement it in Java for our needs in the future (unless your suggest a better idea, wat you will certainly do...). Many thanks for your time & for your advice. Best regards. Philippe.
-- XMLmind XML Editor Support List [email protected] http://www.xmlmind.com/mailman/listinfo/xmleditor-support
