-----Original Message----- From: Daniel Veillard [mailto:veillard redhat com] Sent: Wednesday, March 21, 2007 3:08 AM To: James Dennett Cc: xml gnome org Subject: Re: [xml] Minor documentation path for libxml/xpath.h On Tue, Mar 20, 2007 at 03:10:23PM -0700, James Dennett wrote:The diff below addresses some typos in the documentation of xmlXPathContext. I don't know what format you'd like patches in, or
how
to provoke svn to produce nicer diffs. This is against current svn trunk (revision 3592).Cool, but mail seems to have mangled your patch,
Tragically I have to use Outlook here, and it mangles a good fraction of all e-mail that passes through it.
can you instead regenerate it with svn diff -p and send them as mail attachement which are
usually
perserved by various mail programs, thanks !
svn diff -p xpath.h gives svn: '-p' is not supported with my subversion, version 1.3.2. (Building subversion on Solaris is all kinds of trials; each version gives different obscure errors either during configuration or build.) However, I can use svn diff -x-p -diff-cmd gdiff xpath.h and the output is attached to this message as xpathpatch.txt (though it's passed through a Windows machine and as such Bad Things may have happened to the text file). If this is still the wrong format, let me know and I'll see if I can't win a fight against svn's build process sometime. If only everything were as portable as libxml2 ;-)
(I came to be looking at this as I'm trying to work out which
functions
can modify the context; evaluating an XPath expression can do so,
which
surprised me, but maybe I need to RTFM more carefully.)Usually you should not need to modify the context, except somethings
to
set up the current node or document (and there is no accessor for this requires direct change of the public structure).
It's not that I *want* to modify the context. It's that certain libxml2 functions do so in ways that may not be documented -- in particular, I noted that evaluating an expression using a context appears to change (at least) the current node within that context. I might change my wrapper to restore the node after the expression has been evaluated, but without documenting the contract of the libxml2 functions I can't know that such behavior is sufficient or appropriate. (Our current workaround, and probably a good idea in any case, is for our XPath expressions to be absolute ones.) -- James
Attachment:
xpathpatch.txt
Description: xpathpatch.txt