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

On Wed, Sep 11, 2002 at 09:52:13AM -0400, Daniel Veillard wrote:
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

oh, actually i ment: to reuse previously declared namespaces.

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.

yes, from that part it did a good job. on the other hand this is sometimes not
what people are expecting to get after cut/paste operations :)

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.

i thought it would||should recognize previously defined namespaces as well, that's why 
i patched it.
if my asumptation is correct and this is the wrong behaviour, i could provide
a patch that fixes it. 

  Why not ...

ok. i attched a diff against the cvs repository. the patch is not complete, since
it does not handle namespace declarations like 

    <A xmlns="foo"><B xmlns:C="foo" C:D="bar"/></A>

correctly. but for a range of operations it should work correct. With the current interface 
of xmlSearchNsByHref() it is not too easy to find the correct namespace if the namespaces 
are declared on different elements. something like xmlSearchAllNsByHref() similar to 
xmlGetNsList() would be helpsome in such cases.

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.

actually this depends on what an application should do :) i realize in my context that
XML namespaces become more important. in companion to this operations on namespaces 
are expected to work as on other nodes. shurely namespace nodes do not need to be as 
complex as ordinary nodes although i would expect some basic tree operations to work
even for these nodes.

i agree to minimize api incompabilities i think this can be solved as this is done
with the introduction of the '_private' attribute to the xmlNs structure - although
it is not the most beautiful think to do. 

at least the provided patch could be faster, if namespaces would have 'parent' 
and 'prev' pointers. in documents with a lot of different namespaces it could become
important, since DOM normalization functions are already expensive enough. 


Attachment: cvs_tree_diff
Description: Text document

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