ruffsl <roxfox...@gmail.com> added the comment: Hello @scoder,
Thanks for looking into this. In addition to what I mentioned with lxml's use of the parent xml file's respect dirname when attempting to open the include element's href, do you think it would be possible to (optionally or by default) have the include processor provide the necessary xml:base attributes for compliance with the specification [1][2][3]. I know lxml partially does this, but not for recursive includes beyond a depth of one. Without this, it makes it impossible to track down the subsequent source for deep include paths, i.e. when you'd like to trace from what sequence of includes contributed the element in question. >From looking at the "fixed2", although the added lines 137-143 in >ElementInclude.py appear to prevent infinite recursive includes, but I think >it also prevents valid merging of include trajectories when expanding the tree >of include paths. E.g. what happens if I state the inclusion of the same >source multiple times elsewhere in the same file, or elsewhere in the include >tree that is no way a sub-child of the current parent file. Isn't `already_included` unnecessarily global in scope, when it just need to be relative to the trajectory in the sequence of current branches; only checking a node is not simultaneously a parent and child along a single include trajectory? [1] https://stackoverflow.com/a/22791471/2577586 [2] https://www.w3.org/TR/xmlbase/ [3] http://xerces.apache.org/xerces2-j/faq-xinclude.html#faq-3 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20928> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
