[ http://issues.apache.org/jira/browse/XERCESJ-1104?page=all ]
     
Michael Glavassevich resolved XERCESJ-1104:
-------------------------------------------

    Resolution: Won't Fix

There are several subinterfaces of XMLResourceIdentifier which are passed to 
XMLEntityResolver.resolveEntity(XMLResourceIdentifier). A XMLResourceIdentifier 
for an entity will also be an instance of 
org.apache.xerces.impl.XMLEntityDescription. If it's a grammar it will be a 
org.apache.xerces.xni.grammars.XMLGrammarDescription. If the grammar is a DTD 
it will also be a org.apache.xerces.xni.grammars.XMLDTDDescription. If the 
grammar is an XML schema it will also be a 
org.apache.xerces.xni.grammars.XMLSchemaDescription. With an instanceof check 
you can tell what type of resource is being resolved and if there isn't a 
subinterface for a particular type of resource it's because there hasn't been a 
specific need for one.

This leads me back to what I've said from the start. You can already do what 
you want. The resolveEntity methods on XMLCatalogResolver are just there for 
convienence. If one of the resolve methods doesn't do what you want/need you 
can override it by extending the class. I admit that XNI could have had a 
better design for resource resolution but we're stuck with what we have. The 
changes you've suggested add methods to interfaces which are already in use and 
change the circumstances in which the existing ones are called. When you do 
this (see discussions on the net about DOM Level 3) it causes grief for both 
established users and implementers. We've made minor changes to XNI in the past 
but those have all been critical for supporting the latest version of JAXP. I'm 
against making changes that would break applications which use XNI and other 
implementers of XNI (yes there are a few others than Xerces) when the change 
shuffles around capability which is already there, even if the proposed changes 
are in principle a better design than the existing one.

> 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]

Reply via email to