Hi, Andreas Degert wrote:
I assume it is legal to have to following namespace declaration/usage:
<top xmlns="a" xmlns:a="a" xmlns:b="b"> <foo bar=""/> <b:foobar a:bar=""/> </top>
Sure, the spec calls this well-formed XML - not talking aesthetics, though.
It works when I read such a definition with lxml.etree.parse, but I can't construct it with lxml.etree.Element because then the nsmap dict will be normalized in such a way that each URI occurs only once.
Finally someone complaining that there are too *few* namespace declarations instead of too many. ;o) lxml does a lot of work behind the scenes to keep namespaces consistent and simple throughout whatever operation you affect at the API level. In the case you describe, lxml checks on each new namespace prefix declaration if that namespace is already defined in the tree context of the Element and reuses the old prefix if that is the case. The function that does that is _initNodeNamespaces() in apihelpers.pxi, in case you're interested.
Is this a bug in lxml or shouldn't it be used in this way?
I don't see the use case. What could you do with redundant namespace prefix declarations that you can't do with a single one? Imagine you have two prefixes defined for a namespace and you add a subelement with that namespace. Which prefix should be used? What purpose does that ambiguity serve? Stefan