Hi Eliot, I see that you filed a bug against Xerces: http://issues.apache.org/jira/browse/XERCESJ-1104 Note that it uses an XMLEntityResolver interface (not the SAX EntityResolver) that is at XNI level and that should allow some control over system versus uri mappings if the XMLEntityResolver set uses an XML Catalog. This is the interface I thought we should implement to allow the uri mapping. The XMLEntityResolver interface defines one method: public XMLInputSource resolveEntity(XMLResourceIdentifier resourceIdentifier) and the XMLResourceIdentifier has the following fields: publicId expandedSystemId literalSystemId baseSystemId namespace So basically in a catalog aware implementation of the XMLEntityResolver one can try to see if a namespace is specified and if it is then try to map that namespace through the catalog uri mappings to a resource, if that fails then it can try to map the system ID to a resource using also uri mappings. I'm not sure however what that gives for a no namespace schema for instance. I will watch the bug to see the feedback from Xerces developers. Best Regards, George --------------------------------------------------------------------- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com Eliot Kimber wrote:
George Cristian Bina wrote:
The current behavior is to try to resolve a URI via the net and only if that fails, try the catalog. I would like the option of doing the reverse, namely attempting to do all resolution locally first.
As far as we know/tested oXygen does not do that, and cannot do that. The catalog resolver acts as an entity resolver on the parser so it is called first to resolve an entity. Also I am not aware of any parser that will perform such a fallback as you describe, to try to access a resource and to fallback to something else if that fails.
Hmm--I must have misunderstood the implications of the original failures I was seeing. Since I have to look into the core Xerces code that does entity resolution and schema lookup (see below) I'll poke into this more.
By recursion I mean getting to the same id, for instance direct recursion: map http://www.example.com to http://www.example.com indirect recursion: map http://www.example.com/1 to http://www.example.com/2 map http://www.example.com/2 to http://www.example.com/1
I would call this circular references (cycles). One would have to detect cycles--any process that does recursive lookup in any context must do cycle detection.
But again, if this is all built-in Xerces behavior then of course there's nothing y'all should do.
There is one more issue I think. If we will implement this support for using URI mappings for resolving schemas then if someone tries to validate the document from command line using the Apache resolver at SAX level then he will get a different behavior as that will use the system mappings.
I'm starting to understand the issue a bit more and I agree that this is really an issue with the low-level parser implementation.
I'm trying to find where in the the Xerces code it is resolve schema locations as system IDs rather than URI calls. I think the correct solution is to fix the code at the parser level, so I don't think there's anything oXygen needs to do or could reasonably do about this.
Cheers,
E.