[
http://issues.apache.org/jira/browse/XERCESJ-1104?page=comments#action_12331645
]
William Eliot Kimber commented on XERCESJ-1104:
-----------------------------------------------
I think you're misunderstanding what the problem is that I'm referring to.
The issue, as I see it, is this:
1. In XMLSchemaLoader, in the resolveDocument() method, the loader calls
resolveEntity() on the entityResolver.
2. In XMLCatalogResolver, the resolveEntity() method *only* considers the
systemId and publicId properties of the resource descriptor:
if (resolvedId == null) {
String publicId = resourceIdentifier.getPublicId();
String systemId = getUseLiteralSystemId()
? resourceIdentifier.getLiteralSystemId()
: resourceIdentifier.getExpandedSystemId();
if (publicId != null && systemId != null) {
resolvedId = resolvePublic(publicId, systemId);
}
else if (systemId != null) {
resolvedId = resolveSystem(systemId);
}
}
return resolvedId;
This is the correct implementation for *resolveEntity()* because XML entities
(as opposed to non-entity resources) are *only* resolved via SYSTEM and PUBLIC
entries. That is, a correct implementation of OASIS Entity Resolution catalog
processing *cannot* use URI entries (directly) to resolve entities, therefore,
this is the only possible way that a catalog resolver can work.
This means, that with this implementation, *it is impossible* for
XMLSchemaLocation to resolve schema references via URI catalog entries.
Thus there needs to be a way to indicate that what you want to resolve is in
fact *not an entity* (and therefore is resolved via URI entries and not PUBLIC
or SYSTEM entries.
My engineering practice says that the clearest way to make that distinction is
with the method name.
It could also be done by adding another property to the resource descriptor to
indicate whether it is in fact an entity or a non-entity resource. This would
work but would be much less clear to observers than having a clearly-named
method that only resolves resouces. Since entity resolution only happens during
parsing and anything done that isn't parsing *can't be* entity resolution, I
don't see that there would ever be ambiguity about which method to call in a
given circumstance, since you always know if you're doing XML parsing or if
you're not. (For example, resolving XIncludes *is not XML parsing* and
therefore the resolution of XInclude href= values should be via URI catalog
entries, not SYSTEM or PUBLIC, just as for schemas. But I am now sure that this
code is incorrectly using resolveEntity() as currently implemented to do this
resolution. Thus my assertion that this is an architectural problem in Xerces.
Progress report: I have my test case working to the degree that my schema is
loaded when I parse my test document. This required that I add an
implementation of resolveResourceByUri() to XMLEntityResolver(). What I still
haven't figured out is how to configure the parser so that the schema loader is
initialized with the XMLCatalogResolver rather than the default
XMLEntityResolver--I haven't yet found the documentation for or a sample of how
to set that up.
> Resolution of schemaLocation URIs should be via URI resolution, not entity
> resolution
> -------------------------------------------------------------------------------------
>
> Key: XERCESJ-1104
> URL: http://issues.apache.org/jira/browse/XERCESJ-1104
> Project: Xerces2-J
> Type: Bug
> Components: XNI
> Versions: 2.6.0, 2.7.1
> Environment: All
> Reporter: William Eliot Kimber
>
> The resolveSchema() method of XSDHandler uses the entityResolver to resolve
> URIs in schema location hints. This has the effect that, when using a catalog
> resolver that SYSTEM entries are used to resolve the schema URIs.
> However, schemas are not entities and therefore their URI references should
> not be resolved via an entity resolver but via a URI resolver and should,
> therefore be resolved via URI catalog entries, not SYSTEM entries.
> That is, by the OASIS Entity Resolution spec one would expect to declare URI
> entries to remap schema location URIs but this does not work.
> I'm happy to develop a fix but it may take me a while to figure out exactly
> how to go about it.
> Because this behavior has been around for a while (since at least version
> 2.6) and is documented in at least one tutorial I found, it will probably be
> necessary to control the use of an entityResolver or URI resolver through a
> system property.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
