Thanks! That answers my questions. The apparent asymmetry of handling nodes was confusing, but the distinction of pytypes vs xsi makes some sense. I would naively agree that a seemingly general purpose function like deannotate should remove everything. Otherwise, I have to walk the tree twice: once with deannotate and once to unlink remaining nill types. Or recreate my own deannotate(). Not a big deal either way, though.<br>
<br><div class="gmail_quote">On Tue, Jun 2, 2009 at 12:24 PM, Stefan Behnel <span dir="ltr"><<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<div class="im"><br>
Holger wrote:<br>
>> The nil node <Fubar/> is not deannotated as I would expect in the<br>
>> following<br>
>> snippet. I could not find a reference to this behaviour in the archives<br>
>> or<br>
>> documentation. Is this a design feature for which there is a work around,<br>
>> or a bug? I'm using lxml-2.2-py2.5-linux-i686.<br>
><br>
> Design feature.<br>
<br>
</div>I'd be a little more careful with such a big word. ;)<br>
<div class="im"><br>
<br>
> Only py:pytype/xsi:type attributes get removed by deannotate():<br>
><br>
>>>> print etree.__version__<br>
> 2.1.5<br>
>>>> help(objectify.deannotate)<br>
><br>
> Help on built-in function deannotate in module lxml.objectify:<br>
><br>
> deannotate(...)<br>
> deannotate(element_or_tree, pytype=True, xsi=True)<br>
><br>
> Recursively de-annotate the elements of an XML tree by removing 'pytype'<br>
> and/or 'type' attributes.<br>
><br>
> If the 'pytype' keyword argument is True (the default), 'pytype' attributes<br>
> will be removed. If the 'xsi' keyword argument is True (the default),<br>
> 'xsi:type' attributes will be removed.<br>
<br>
</div>Yes, so it's even implicitly documented. :)<br>
<br>
Anyway, I'm not sure it's always a good idea to leave this special case in<br>
instead of cleaning everything up. I think if you remove it, you'd get an<br>
empty string result, which may be surprising - but more surprising than not<br>
getting it cleaned up? After all, deannotate() means deannotate()...<br>
<font color="#888888"><br>
Stefan<br>
<br>
</font></blockquote></div><br>