Re: [xml] Minor documentation path for libxml/xpath.h

-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com]
Sent: Wednesday, March 21, 2007 9:51 AM
To: James Dennett
Cc: xml gnome org
Subject: Re: [xml] Minor documentation path for libxml/xpath.h

On Wed, Mar 21, 2007 at 09:16:40AM -0700, James Dennett wrote:
... the output is attached to this message as xpathpatch.txt 
...  If this is still the wrong format, let me know.

  Nah, that worked just fine, applied and commited, thanks a lot !

Taking a little time to prepare patches is a small price
for the value I/we get from libxml2!


It's not that I *want* to modify the context.  It's that certain
functions do so in ways that may not be documented -- in particular,
noted that evaluating an expression using a context appears to
(at least) the current node within that context.  I might change my
wrapper to restore the node after the expression has been evaluated,
without documenting the contract of the libxml2 functions I can't
that such behavior is sufficient or appropriate.

(Our current workaround, and probably a good idea in any case, is
our XPath expressions to be absolute ones.)

  Right evaluation may change the node (and possibly the doc but only
an XSLT context so it should not affect you). In any case if you have
relative expressions, then you definitely need to set up the node
calling the evaluation. Other items which influence evaluation are
namespaces/nsNr the context namespaces, here/origin used in XPointer,
registered functions and the dictionnary if any . But those should not
be modified by evaluation.

OK, perfect; I'll make our code set the node, but also caution in its
documentation against using relative expressions in any case -- there
should be no good reason for using relative expressions when there's no
clearly-defined node for them to be relative *to*.

-- James

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]