[oXygen-user] Working with Catalogs

Eliot Kimber
Wed Oct 5 09:20:19 CDT 2005


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.

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841


www.innodata-isogen.com




More information about the oXygen-user mailing list