Re: XML Catalogs in Xerces

Hi George,

We think there is a need for another
utility class.  By default the resolver uses JVM wide system properties
and/or a properties file to determine the settings used by the catalog.
 Unless you provide one, the CatalogResolver uses a static CatalogManager.
 The documentation doesn't make it obvious as to how one would make
the CatalogResolver work with per instance preferences.  This behaviour
may be harmful, especially if multiple apps want to use catalogs at the
same time.  Xerces ships with the JDK.  We should provide something
which doesn't allow other applications running in the same JVM from trampling
another application's settings.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@xxxxxxxxxx
E-mail: mrglavas@xxxxxxxxxx

"George Cristian Bina" <george@xxxxxxx>

01/20/2004 05:27 PM

Please respond to
xerces-j-user

To	<xerces-j-user@xxxxxxxxxxxxxx>
cc
Subject	Re: XML Catalogs in Xerces

Hi Michael,
 
There should be no need for this, the CatalogResolver
class from org.apache.xml.resolver.tools already implements the EntityResolver
interface. Also I guess the EntityResolverWrapper class can be used to
adapt it to XNI entity resolver.
 
We implemented XML Catalog support a few
months ago in oXygen using the xml-commons resolver on top of Xerces. The
only thing we needed was to be able to pass to the parser the catalog resolver
but also some other entity resolver, so you may consider adding an utility
class like ForkEntityResolver or CompoundEntityResolver that will get two
resolvers on the contructor and if the first one does not resolve the entity
the second one will be called.
 
Best Regards,
 George
-------------------------------------------------------
George Cristian Bina mailto:george@xxxxxxxxxxxxx
<oXygen/> XML Editor - http://www.oxygenxml.com/
----- Original Message ----- 
From: Michael
Glavassevich 
To: xerces-j-user@xxxxxxxxxxxxxx

Sent: Tuesday, January 20, 2004 11:53 PM
Subject: Re: XML Catalogs in Xerces


Sure that sounds reasonable. 

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@xxxxxxxxxx
E-mail: mrglavas@xxxxxxxxxx

Bob Foster <bob@xxxxxxxxxx>

01/20/2004 04:47 PM

Please respond to
xerces-j-user

To	xerces-j-user@xxxxxxxxxxxxxx
cc
Subject	Re: XML Catalogs in Xerces

Hi,

Sounds good. While you're up, could you have your utility class 
implement EntityResolver, as well, so it can be used at the SAX level?

Bob Foster
http://xmlbuddy.com/

Michael Glavassevich wrote:
> 
> Hi everyone,
> 
> We've been re-evaluating our original approach for including support
for 
> XML catalogs. Instead of adding a new parser property we think it
would 
> be better to use the existing entity resolver property and make what
> would have been a catalog manager an implementation of XNI's 
> XMLEntityResolver which would probably live in the util package.  We
> would provide an implementation of resolveEntity but users could 
> override it to do something else.  They could also use the source
of the 
> class we provide as a template for creating catalog resolvers for
other 
> types of catalogs.  Having disjoint resolvers forces that we
come up 
> with an order for calling them (with no spec to base on which to base
a 
> decision) which we originally did but we're now aware of several use
> cases where consulting the catalog and then calling an entity resolver
> isn't the appropriate thing to do.  Having that behaviour built
into the 
> parser would work for some but certainly not everyone, and since what
we 
> were discussing looked very much like an entity resolver anyway, why
> call it something else?
> 
> I propose we just have a utility class (for now) as well as including
> the XML commons resolver with the parser.
> 
> Michael Glavassevich
> XML Parser Development
> IBM Toronto Lab
> E-mail: mrglavas@xxxxxxxxxx
> E-mail: mrglavas@xxxxxxxxxx



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xxxxxxxxxxxxxx
For additional commands, e-mail: xerces-j-user-help@xxxxxxxxxxxxxx