![](https://secure.gravatar.com/avatar/947c14f160f3305b9e7f54c0cc9708a1.jpg?s=120&d=mm&r=g)
Stefan Behnel wrote:
Luke Tucker wrote:
It wouldn't be on the C side, but I think lxml might stick close enough to the ElementTree api to use their python xinclude implementation (ElementInclude.py) which does support the specification of a resolver if you need it. If you don't want to use that directly, it's probably a decent example. There is also a modified version of it that we use with lxml in Deliverance, but it's recursive I believe.
It is, right. For a Python-based solution in lxml, I'd personally prefer something based on getiterator("{http://.../xinclude}include"), should be much faster.
Maybe we could even switch to something like that internally in lxml...
I'm fine with supporting something Python-based in addition to the libxml2 version, but I think the XInclude implementation in libxml2 has the benefit in that it's probably fairly complete and besides, *they*'re maintaining it, not us. :) So, I'm fine with adding our own XInclude support, as long as it's in addition and not a replacement, along the same lines as the way we support ElementTree's 'find' together with our own 'xpath'. Once the remaining buildout issues get taken care of it'll be a lot easier to work with lxml and newer versions of libxml2. This may enable us to push against libxml2 a bit harder. Regards, Martijn