Fredrik Lundh wrote:
> "Chris S" wrote:
>
>> and 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
>
> ET's not a canonicalization library, and doesn't claim to be one, so that
> reference isn't
> ver
Martin v. Löwis wrote:
> That is not enough reason. Yes, it makes certain applications
> impossible, e.g. when namespace prefixes are inside attribute
> values. It just means you can't use it for that application,
> then. XML has many other applications, and so does ElementTree.
there are ways to
"Chris S" wrote:
> and 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
ET's not a canonicalization library, and doesn't claim to be one, so that
reference isn't
very relevant. And "most users" know t
Chris S schrieb:
> I'm happy to see Elementtree being considered for inclusion with 2.5.
> However, before committing to this decision, there's an issue
> regarding it's namespace parsing that should be addressed. Although
> Elmenttree is in most respects an excellent XML parser, a huge gotcha
> th
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
I'm happy to see Elementtree being considered for inclusion with 2.5.
However, before committing to this decision, there's an issue
regarding it's namespace parsing that should be addressed. Although
Elmenttree is in most respects an excellent XML parser, a huge gotcha
that often makes Elementtree
