[oXygen-user] Working with Catalogs

[George Cristian Bina]

Hi Eliot,

There are two requirements that we extracted from these emails:

1. Allow multiple levels of indirection through the catalog mappings
2. Use uri mappings instead of system mappings for schema locations

We will consider both, the second one is a little more difficult to 
implement.

The first requirement also needs attention as the catalogs may contain 
direct or indirect recursion.

We are using currently the catalog as an EntityResolver set on the XML 
parser thus it is not possible to use uri mappings as all we get at that 
level is a resolveEntity call. Using uri mappings requires usage of 
parser specific support, in our case working at XNI (Xerces Native 
Interface) level.

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Eliot Kimber wrote:
> Eliot Kimber wrote:
>>     That is, I was hoping that the entity resolution would work as 
>> follows:
>>
>> Step 1: resolve system ID 
>> "http://dita.oasis-open.org/DITA/version.1/topic.dtd" to URI 
>> "http://dita.oasis-open.org/DITA/version.1.0/topic.dtd"
>>
>> Step 2: try to reslve URI 
>> "http://dita.oasis-open.org/DITA/version.1.0/topic.dtd" via catalog, 
>> resolve it to URI "./topic.dtd"
>>
>> Step 3: try to reslve URI "./topic.dtd" via catalog. Find no entry, 
>> try to resolve it using outside system, find local file topic.dtd.
>>
>> However, it appears that Oxygen's resolver does not try to resolve the 
>> URI returned in step 1, causing it to fail the validation with an 
>> HttpException.
> 
> Note that this is the behavior of client of the resolver, not the 
> behavior of the resolver itself (which always does just a single 
> lookup). The Entity Resolution spec makes it clear the the resolver does 
> not do recursive entry processing.
> 
> That is, it's the software component that calls the resolve*() method on 
> the resolver that implements the above recursive algorythm, not the 
> resolver.  That's one reason this needs to be an oXygen-level option, 
> because this behavior is a function of the processors integrated with 
> oXygen, not the core resolver (which I presume is the Apache commons 
> resolver).
> 
> Cheers,
> 
> E.
>