Update to Question 1 I have created a simpler example which I will share with you, hopefully tomorrow. This uses local resources and simple XSDs which I've crafted. The behaviour, when using my `SimpleFileResolver` class, of failing to expand the full URL is reproduced. I'll share the code and resources when I have time to put it all together in a neat form, as I say, hopefully tomorrow. Also, I've noticed some additional strangeness with the URLs when resolving `<include>` elements for resources referenced by just their filename (perhaps for any relative path). The parser builds the absolute path from the relative one, but in the form `file:{unix_path}/resource.xsd`, instead of `file://{unix_path}/resource.xsd`<file://{unix_path}/resource.xsd>. This means that (e.g.) `urllib3.util.url.parse_url` doesn't recognise this path as a being of `file` type scheme which causes issues. Better explanation of this one tomorrow. I will also try to find where these issues are stemming from in the source, so hopefully I can say something about it with relevance to the lxml code. Any helpful directions on where to look will be appreciated! Cheers, Rg. ________________________________ 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. ________________________________