I have encountered a problem when using xs:include and the commons resolver together. It has been reported before, as XERCESJ-1613. I posted the following as a comment on that issue in Jira.
I believe this issue is caused by a bug in org.apache.xerces.util.XMLCatalogResolver.resolveIdentifier: // The namespace is useful for resolving namespace aware // grammars such as XML schema. Let it take precedence over // the external identifier if one exists. String namespace = resourceIdentifier.getNamespace(); if (namespace != null) { resolvedId = resolveURI(namespace); } That is not the correct action when processing an xs:include element. We should resolve the schemaLocation hint in the xs:include element, not the namespace URI of the schema document containing the xs:include. One possible patch is as follows: // The namespace is useful for resolving namespace aware // grammars such as XML schema. Let it take precedence over // the external identifier if one exists (except for include) String namespace = resourceIdentifier.getNamespace(); XSDDescription desc = (XSDDescription)resourceIdentifier; if (namespace != null && desc.getContextType() != XSDDescription.CONTEXT_INCLUDE) { resolvedId = resolveURI(namespace); } A workaround is to change the uri element in the catalog file into a system element. This is arguably incorrect - the schemaLocation hint in an xs:include element is not an external identifier - but it does work. -- Dr. Scott Renner, The MITRE Corporation Phone: +1 703-983-1206 (office); +1 978-831-2598 (cell) --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org