Update on this issue (Question 1): I've created a minimal example of the issue of the path construction issue when an import is used (test_1.tar.gz). In this example, the loss of the re-constructed path occurs with the <import>'d resource itself; the original example had this occurring with a resource <include>'d by the <import>'d resource, but the limitations of a portable example mean that the <import>'d resource has a relative link in the XML. I have looked at <include>'ing more resources from the first namespace (test_2.tar.gz) and found that this is not expanded properly either. So it seems that the first include/import works, but subsequent ones do not. This may simply be related to the reported bug here: https://bugs.launchpad.net/lxml/+bug/1568167 This bug report states the the base_url parameter does not work for the resolve_* methods. Incidentally, what's nice is that the resolve_filename method works as well as the default resolver for this example. I'll have to work on simplifying Question 2, to see if I have a solution already. Roger ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. ________________________________