List Info

Thread: Re: Minor documentation path for libxml/xpath.h




Re: Minor documentation path for libxml/xpath.h
country flaguser name
United States
2007-03-21 11:16:40
> -----Original Message-----
> From: Daniel Veillard [mailto:veillardredhat.com]
> Sent: Wednesday, March 21, 2007 3:08 AM
> To: James Dennett
> Cc: xmlgnome.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


_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

  
Re: Minor documentation path for libxml/xpath.h
user name
2007-03-21 11:50:40
On Wed, Mar 21, 2007 at 09:16:40AM -0700, James Dennett
wrote:
> >   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.

  heh

> > 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

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

> >   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.)

  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.

  thanks again !

Daniel

-- 
Red Hat Virtualization group http://redhat.com/v
irtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillardredhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ |
Rpmfind RPM search engine  http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )