[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] Minor documentation path for libxml/xpath.h
- From: "James Dennett" <jdennett technocom-wireless com>
- To: <xml gnome org>
- Subject: Re: [xml] Minor documentation path for libxml/xpath.h
- Date: Wed, 21 Mar 2007 11:01:53 -0700
> -----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!
[snip]
> > 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.)
>
> Right evaluation may change the node (and possibly the doc but only
in
> 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
before
> 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]