Exclusive canonicalization ignores inclusive_ns_prefixes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
lxml |
New
|
Undecided
|
Unassigned |
Bug Description
I'm trying to use the write_c14n method on ElementTree with exclusive=True and a list of prefixes provided to the inclusive_
Unfortunately, it seems that the inclusive_
I have taken my example from Section 2.2 of the Exclusive XML Canonicalization specification: https:/
First, let's start with an inclusive canonicalization:
Here's the source XML:
<n0:local xmlns:n0="http://
<n1:elem2 xmlns:n1="http://
<n3:stuff xmlns:n3="http://
</n1:elem2>
</n0:local>
And here's its representation with ElementMaker objects, as well as the code to produce the canonicalization:
from lxml.builder import ElementMaker
from lxml.etree import ElementTree, Element
from lxml import etree
from StringIO import StringIO
def stringify(elem):
f = StringIO()
et = ElementTree(elem)
et.
f.seek(0)
return f.read()
n0 = ElementMaker(
n1 = ElementMaker(
n3 = ElementMaker(
elem = n0.local(
print stringify(
The output of the print statement produces:
<n1:elem2 xmlns:n0="http://
Now, in the et.write_c14n call, let's say I change to exclusive=True:
<n1:elem2 xmlns:n1="http://
Both of these examples match the output in the W3 webpage I referenced above. In the first output, the parent n0 element provides context that is included in the child. This seems like the correct behavior for an inclusive canonicalization. In the second output, we're in exclusive mode, and namespaces are only included when needed and only if they haven't already been included by an ancestor. All's great so far, so what's wrong?
Well, let's now modify the et.write_c14n call to use have exclusive=True and also provide inclusive_
<n1:elem2 xmlns:n1="http://
Eh? It's exactly the same as in the second output! That's not right. According to our inclusive_
<n1:elem2 xmlns:n1="http://
Notice how the n3 namespace was pushed to the top-level element in my correction. It's odd that lxml didn't produce that on it's own, considering lxml's documentation for the write_c14n method: "The inclusive_
Python : sys.version_
lxml.etree : (3, 8, 0, 0)
libxml used : (2, 9, 4)
libxml compiled : (2, 9, 4)
libxslt used : (1, 1, 29)
libxslt compiled : (1, 1, 29)