Re: [xml] two small patches for libxml2

On Mon, Nov 11, 2002 at 02:36:20PM +0100, Petr Pajas wrote:

Daniel, (All),

1. I've found that xpath evaluation in libxml2 behaves differently on
CData section nodes if I search all text nodes with //text() or just
one of them with //text()[4] (the first of these queries taking CData
section into account while the second not). The attached simple patch
for xpath.c fixes this.

  The XPath data model removed the distinction between cdata nodes and
text nodes, as a result the XPath engine expects to have no CData node
in it, so I'm not surprized. The real fix is to make sure you do not generate
CData nodes at parse time but text nodes instead. Xsltproc does this by
calling the following at initialization time:

     * disable CDATA from being built in the document tree
    xmlDefaultSAXHandler.cdataBlock = NULL;

  But since the patch is fairly simple and unintrusive, I applied it anyway.

2.  I'm using Matt's and
Christian's XML::LibXML Perl bindings and had this written in Perl
which was a bit slow on large documents. Now, when Christian added
bindings for xmlGetNodePath to XML::LibXML I can use your C
implementation. It, however, only computes paths for element and
attribute nodes. The attached patch against tree.c adds implementation
for other types of nodes (PI, text, comments). (I only copied and
I'd be glad if you could review the patches and apply them.

  Looks fine, applied. I assume you tested them :-)

XSH - XML Editing Shell (
The ultimate command-line XML editing and browsing tool.

  BTW the simplest way to test xmlGetNodePath() is to use xmllint --shell
cd in the tree and use pwd to get the node path, yet another command line
XML (and HTML) browsing tool :-)


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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