[oXygen-user] Working with Catalogs

[George Cristian Bina]

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