[oXygen-user] Working with Catalogs

[George Cristian Bina]

Hi Eliot,

See a few comments below.

Eliot Kimber wrote:
> George Cristian Bina wrote:
>> Hi Eliot,
>>
>> There are two requirements that we extracted from these emails:
>>
>> 1. Allow multiple levels of indirection through the catalog mappings
> 
> Yes
> 
>> 2. Use uri mappings instead of system mappings for schema locations
> 
> Yes.
> 
>> We will consider both, the second one is a little more difficult to 
>> implement.
> 
> There is a third requirement, which is provide control over whether to 
> use the catalog first or second when resolving system IDs and URIs.
> 
> 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.


>> The first requirement also needs attention as the catalogs may contain 
>> direct or indirect recursion.
> 
> I'm not sure I follow you here--I think there can only be direct 
> recursion--that is, a given entry either resolves to another URI mapped 
> in the catalog or it doesn't. If it doesn't then you will never return 
> to the catalog (because either you will resolve the resource from where 
> it is served or resolution will fail completely).

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

>> 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. 
> 
> Hmm. Is this an aspect of a standard API behavior or the behavior of the 
> specific parser you're using? I'm not necessarily conversant with this 
> level of detail in SAX or JAXP. If I'm asking for something that's at 
> odds with current APIs perhaps I need to rethink my request (not that 
> the request is incorrect in principle, but if it's in conflict with 
> established, albeit incorrect, practice, far be it from me to buck that 
> trend).

We are using mainly SAX in oXygen, for validation we create an XML 
Reader. At SAX level all you can set on the XML Reader is an 
EntityResolver or since SAX 2.0 an EntityResolver2:
http://www.saxproject.org/apidoc/org/xml/sax/EntityResolver.html
http://www.saxproject.org/apidoc/org/xml/sax/ext/EntityResolver2.html

The methods defined by these interfaces do not provide enough 
information to be able to detect that you are trying to resolve an 
external entity or a schema location, so the issue is with general XML 
API and not with the specific parser we are using which is Xerces 2.7.1.

>   Using uri mappings requires usage of
>> parser specific support, in our case working at XNI (Xerces Native 
>> Interface) level.
> 
> Hmm, OK. I'm not sure what this means at the implementation level, but I 
> assume this means that you've got to use a tighter binding to the parser.

Exactly.

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.

> Cheers,
> 
> E.

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