[Python-Dev] Elementtree and Namespaces in 2.5

Michael Chermside mcherm at mcherm.com
Fri Aug 11 19:38:25 CEST 2006


Chris Spencer writes:
> there's an issue
> regarding [ElementTree's] namespace parsing that should be addressed.
     [... it performs namespace rewriting ...]
> while most users and the w3 spec
> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315#NoNSPrefixRewriting)
> agree this feature is actually a bug, Fredrik Lundh has refused to fix
> this problem. Of course, this is his right. Unfortunately,
> Elementtree's design makes a work-around rather awkward. Therefore, we
> might want to rethink inclusion of Elementtree in the stdlib, or at
> least patch the stdlib's version of Elementtree to produce an output
> more in line with the w3 standard.

The good news for you is that:
  (1) Including ElementTree in the stdlib does not (immediately) take
     away from any of the other XML librarys out there.
  (2) Including ElementTree in the stdlib *increases* the chance that
     requests from users will lead to a change in the library.
  (3) Changing ElementTree to preserve namespace prefixes would be
     backward compatible with a version that didn't preserve it, so
     nothing happening now forecloses fixing this in future releases.

Now, in my opinion, the W3 flubbed badly in the way they designed
namespaces, prefixes, and allowing namespace prefixes to appear
within element content and attributes. Creating a universal namespace
with local aliases to prevent name clashes is nice, making the local
aliases significant so that we haven't prevented name clashes after
all but have merely introduced vast complexity (and *encouraged*
clashes by shortening the names) is... not so nice.

But that's beside the point. Even if we presume 100% agreement on
the need to change ElementTree, the best thing to do is still to
release ElementTree in the stdlib exactly as it is in 2.5 and change
it for 2.6.

-- Michael Chermside



More information about the Python-Dev mailing list