"Re: [xml] xmlReconciliateNs problem"


you may want to use the attached patch, rather than the last one, since 
the bug occured to xmlSearchNs as well.

Kasimier Buchcik wrote:

Petr Pajas wrote:

Hi Daniel, All,

I'm trying to make XML::LibXML perl module work with 2.6. After 
examining one of the self tests that broke after upgrade, I suspect that 
xmlReconciliateNs doesn't do its right job (if at all). The 
documentation says:

"This function checks that all the namespaces declared within the given
tree are properly declared. This is needed for example after Copy or Cut
and then paste operations. ..."

Now, I have a document like this:
<?xml version="1.0"?>
<foo><x:a xmlns:x="http://foo.bar";><x:b/></x:a></foo>

and try either:
a) move <x:b/> one level up, into <foo>
b) move <x:b/> into another document

in both cases, expecting xmlReconciliateNs to create 
xmlns:x="http://foo.bar"; on <x:b/>. This is at least what it used to do 
with libxml2-2.5.x.

The attached file is my lame attempt of rewriting of the test case into 
C. It demonstrates the problem in the following way:

1) run it without parameters to check for a)
2) run it with 1 parameter (arbitrary) to check for b)
3) run it with 2 parameter (-"-) to check for b), freeing the original 
document as soon as <x:b> was moved and namespaces reconciliated.

I compile it with:
gcc -I /usr/include/libxml2 -L /usr/lib -lxml2 -o testns testns.c

with 2.6, I get
1) ./testns
<?xml version="1.0"?>
<foo><x:a xmlns:x="http://foo.bar"/><x:b/></foo>
(bad: x:b has prefix but no namespace declared)

2) ./testns x
<?xml version="1.0"?>

3) ./testns x x
<?xml version="1.0"?>
(even worse - maybe because of the new string reusing code?)

while with 2.5.3:

1) ./testns
<?xml version="1.0"?>
<foo><x:a xmlns:x="http://foo.bar"/><x:b xmlns:x="http://foo.bar"/></foo>
2) ./testns x
<?xml version="1.0"?>
<x:b xmlns:x="http://foo.bar"/>
3) ./testns x x
<?xml version="1.0"?>
<x:b xmlns:x="http://foo.bar"/>

which all look well.

I looked into the corresponding tree.c code. It appears, that 
xmlReconciliateNs simply does nothing, being fooled by xmlSearchNsByHref 
which returns node->ns even though it failed to find a corresponding nsDef.

If the behavior of 2.6 is intended, is there a workaround?

-- Petr

I attached a patch fixing that issue. The new speedup part of the 
function did not prevent the specified node's namespace to be compared 
to the searched one.


Attachment: tree.diff
Description: Text document

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