I believe I'm able to answer my own questions: 1. Use xmlGetNodePath to build the node path instead of rolling a custom function. 2. There is no need to return a copy of a node retrieved by an XPath evaluation - node pointers returned by the query point to the actual node memory in the tree. These nodes do not become invalid when the query object or context are freed.
Thanks, - Paul -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul B. Cameron Sent: Tuesday, May 03, 2011 12:32 PM To: [email protected] Subject: Re: [xml] SelectSingleNode Thank you for your reply, Daniel. Putting the namespace issue aside (I can work around this, as you suggest), I do have another related question. It is probably a bit naïve, so please bear with me. To implement something similar to SelectSingleNode, I am taking an input xmlNodePtr (element) and using it to build an XPath expression using the parent\child link, i.e. so the result is something like "\root\child\grandchild". I pass this to xmlXPathEvalExpression, retrieve the node I want and return a copy of that node using xmlCopyNode. However, since xmlCopyNode does not populate the parent member of the copy I can't use it in future calls to SelectSingleNode, because it won't be able to generate the XPath expression properly. I assume it is not wise to simply populate the parent member of the copy using the original node that was passed into my function. Is there a way to 'find' the DOM node that matches a node returned by an XPath query? Am I going about the whole thing wrong? Thanks, - Paul _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
