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