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: [email protected]
For additional commands, e-mail: [email protected]
