[xml] =?ISO-8859-1?Q?=22Re=3A=20=5Bxml=5D=20usage=20of=20xmlReconciliateNs=22=27?=

Hi Mr. Veillard,

I have some questions about fixing the function "xmlReconciliateNs":
If we try to keep the already declared namespaces in the subtree, we 
have to be sure that the function "xmlNewReconciliedNs" does not create 
a new ns-declaration with a prefix that could be shadowed by an already 
declared namespace in the subtree.


   <b xmlns:foo="fooX">
     <foo:c >
       <foo1:d xmlns:foo1="fooY">
         <e foo:attr=""/>
   <x xmlns:foo="fooZ"/>

If we detach <c>, add it to <x> and perform a "xmlReconciliateNs" we get 
the following serialized result :
(Note that "xmlReconciliateNs" was modified here to preserve existing 
namespace declarations)

   <b xmlns:foo="fooX"/>
   <x xmlns:foo="fooZ">
     <foo1:c xmlns:foo1="fooX">
       <foo1:d xmlns:foo1="fooY">
         <e/ foo1:attr="">

The attribute "attr" is now in the namespace "fooY", but originally it 
was in "fooX".

The only solution I can thing of by now is to enable 
"xmlNewReconciliedNs" to take care of already declared namespaces in the 
subtree as well, when building new prefix names. Note that 
"xmlNewReconciliedNs" does not do this by now.
This is a pain in the ass: every time a reconciliated namespace is 
needed the whole subtree would have to be searched as well - expensive.

So what would you suggest:
   1. turtlelize things to preserve already existent namespace 
declaration structure
   2. recreate and redeclare every already existent declaration at the 
top of the given tree (this is currently done) + removing the old, 
unused declarations (this is currently not done)

Kasimier Buchcik

Daniel Veillard wrote:

That function obviously didn't got much testing, well if you can provide
a patch to fix this, it will certainly be applied. Would be a good thing
to extend the cutnpaste.py test to check the specific behaviours being

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