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