You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by "Renner, Scott A." <sa...@mitre.org> on 2019/01/03 16:12:20 UTC
xs:include and resolver
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-users-help@xerces.apache.org