This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specification requires processors to behave differently depending on whether the schemaLocation in xs:include "fails to resolve" versus whether it successfully resolves and delivers something that is not a valid schema document. It should be noted that it may be very difficult to distinguish these two cases. For example, there are two tests schB8 and schE9 that attempt to use the schemaLocation http://foo/foo in xs:include and xs:import respectively. With some internet providers, this URI will fail to resolve. With other internet providers, it will resolve to an HTML document saying that the domain name does not exist and inviting the user to purchase it. (This HTML document will typically be parsed as XML and fail to parse.) So this distinction is entirely outside the implementor's control, and clauses requiring (with an emphatic MUST) the processor to distinguish the two cases are unenforceable. I think that despite the "MUST", a processor that takes the same action in both cases would be conformant.
WG proposal: add a statement to the paragraph beginning "It is not an error ..." saying that at user option a processor MAY treat it as an error. Make this change to features like "include".
A diffed version of the spec showing a draft erratum for this issue is now on the server at https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.errata-2012.html (member-accessible link) Accordingly, I'm marking the issue as needs review. Michael, please note that your bug report specifically mentions the treatment of failure to resolve on xs:include and does not mention the similar wording used for xs:import. After a superficial examination of the text, I made the change apply to both include and import. Oddly enough, I did not see similar wording for redefine or override; perhaps someone should make a more systematic search before we close this issue.
The draft errata document https://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.errata-2012.html has changes to address this bug. We request Michael Kay to take a look and comment, please.
The proposed change looks OK to me.