Re: [xml] does xmlReconciliateNs() its job incomplete?

On Wed, Sep 11, 2002 at 02:02:41PM +0200, Christian Glahn wrote:
hello daniel, all,

while testing i found xmlReconciliateNs() ignores namespaces previously defined
in the (optional) parent tree. i though the correct behaviour of this function
was to fix the namespace declarations in the entire tree.

  Hum, in the subtree actually

for example adding '<foo:elem xmlns:foo="bar"/>' to the root element of 
the following document

<?xml version="1.0"?>
<foo:root xmlns:foo="bar"/>

will result

<?xml version="1.0"?>
<foo:root xmlns:foo="bar"><foo:elem xmlns:foo="bar"/></foo:root>

instead of (what i would expect)

<?xml version="1.0"?>
<foo:root xmlns:foo="bar"><foo:elem/></foo:root>

  Well the implementation did only the work needed to make the result a
correct document w.r.t. namespaces when reserializing, not to "optimize"
the namespace generation.

after running xmlReconciliateNs() on that element. i don't think this the 
intended behaviour (or at least it looks wrong to me). 

  Well, it's not wrong, but it's not minimal.

if my asumptation is correct and this is the wrong behaviour, i could provide
a patch that fixes it. 

  Why not ...

also i wonder why the parent node of a namespace declaration is 
not available from the declaration itself. i remember this issue was discussed
some time ago, but i can't remember (nor find) why only the '_private' member 
was added to the xmlNs structure. i think some operations could be speeded 
up (e.g.  reconciliate) if the parent node would be available.

  Because I wanted to keep xmlNs nodes as small as possible, and minimize
ABI incompatbilities. Agreed this could simplify a lot of things, but usually
namespaces are not manipulated heavilly, far less than other nodes.


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]