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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
