[lxml-dev] pretty-printing

Hi! I've posted a question about pretty-printing some time ago. Now I finally found the time to construct an example. The problem occurs with the following code: nsmap = dict (foo="http://foo.org", bar = "http://bar.org") e = Element("{http://foo.org}somefoo", nsmap = nsmap) s = Element("{http://bar.org}somebar", nsmap = nsmap) e.append(s1) et = ElementTree(e) et.write("foo.xml", pretty_print = True) This code creates the following XML file: <foo:somefoo xmlns:foo="http://foo.org" xmlns:bar="http://bar.org"> <bar:somebar xmlns:foo="http://foo.org" xmlns:bar="http://bar.org"/> </foo:somefoo> The problem is that "bar:somebar" redundantly declares the namespaces for "foo" and "bar", which affects both the readability and the size of the XML file. If the element "s" is appended to "e" by using the SubElement function instead of "append", the content of the XML file looks like I'd expect: <foo:somefoo xmlns:foo="http://foo.org" xmlns:bar="http://bar.org"> <bar:somebar/> </foo:somefoo> Is this a known bug? Thanks & best regards, Albert Brandl

Hi, Albert Brandl wrote:
I get the same here.
True. Doesn't affect it's semantics, though.
That case is easier to handle than the above, so lxml/libxml2 optimises it.
Is this a known bug?
It's known - though not really a bug but rather an inconvenience. Currently, we use a function in libxml2 called xmlReconciliateNs() to fix the namespaces when merging trees. This function shows the above behaviour. To fix this, we'd have to implement our own version, which is a bit tricky and just wasn't important enough to try to get right so far. Note that even libxml2 had a (minor) bug up to version 2.6.26 here, so it's really not trivial to get this kind of thing right. Stefan

Hi! Thanks for the reply. On Wed, Nov 22, 2006 at 09:40:43PM +0100, Stefan Behnel wrote:
It's not that important, and I'll find a way to use SubElement instead of append. I just wanted to make sure that you know about this somewhat unexpected behaviour. Regards, Albert

Hi again, Stefan Behnel wrote:
I finally took a(nother) shot at it and I now have an implementation that can avoid this kind of problem. It's currently stored in the "nscleanup" branch, but I will move it to the trunk ASAP. Please give it a try then, to see if it works nicely for you in other cases where you encountered this. Stefan

Hoi On 2006-12-04 08:49:22 +0100, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> said:
That has not made it to the latest release, has it? Any plans to get it in? -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

Hi, Christian Zagrodnick wrote:
It's still on the list. It didn't make it into 1.2, as I couldn't find the time to make it work correctly. It still doesn't pass all of our test cases. I know for myself how important this change is and I'll try to get it in soon. The merge will just have to wait until it really works. This is a very critical function that can break a horrible lot of things in an unexpected way. Once it works, there will definitely be a beta version before it gets its final blessing. Stefan

Hi, Albert Brandl wrote:
I get the same here.
True. Doesn't affect it's semantics, though.
That case is easier to handle than the above, so lxml/libxml2 optimises it.
Is this a known bug?
It's known - though not really a bug but rather an inconvenience. Currently, we use a function in libxml2 called xmlReconciliateNs() to fix the namespaces when merging trees. This function shows the above behaviour. To fix this, we'd have to implement our own version, which is a bit tricky and just wasn't important enough to try to get right so far. Note that even libxml2 had a (minor) bug up to version 2.6.26 here, so it's really not trivial to get this kind of thing right. Stefan

Hi! Thanks for the reply. On Wed, Nov 22, 2006 at 09:40:43PM +0100, Stefan Behnel wrote:
It's not that important, and I'll find a way to use SubElement instead of append. I just wanted to make sure that you know about this somewhat unexpected behaviour. Regards, Albert

Hi again, Stefan Behnel wrote:
I finally took a(nother) shot at it and I now have an implementation that can avoid this kind of problem. It's currently stored in the "nscleanup" branch, but I will move it to the trunk ASAP. Please give it a try then, to see if it works nicely for you in other cases where you encountered this. Stefan

Hoi On 2006-12-04 08:49:22 +0100, Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> said:
That has not made it to the latest release, has it? Any plans to get it in? -- Christian Zagrodnick gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

Hi, Christian Zagrodnick wrote:
It's still on the list. It didn't make it into 1.2, as I couldn't find the time to make it work correctly. It still doesn't pass all of our test cases. I know for myself how important this change is and I'll try to get it in soon. The merge will just have to wait until it really works. This is a very critical function that can break a horrible lot of things in an unexpected way. Once it works, there will definitely be a beta version before it gets its final blessing. Stefan
participants (4)
-
Albert Brandl
-
Christian Zagrodnick
-
Stefan Behnel
-
Stefan Behnel