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. christian
Attachment:
cvs_tree_diff
Description: Text document