Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] URI (and question re: catalog resolvers)

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Michael Abato <mrabato AT earthlink.net>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] URI (and question re: catalog resolvers)
  • Date: Tue, 6 Apr 2004 13:03:17 -0400

On Apr 6, 2004, at 11:10 AM, Elliotte Rusty Harold wrote:

Since XOM is already "in the business" of picking parsers an has set the
"easy to learn" design objective, I think it would be a great service to reflectively
detect the resolver and create a resolving parser if possible. I believe this would
only effect the semantics of the Builder ctor and the system-specific details
of the underlying parser, and so could even be considered for 1.0. Failing
that, a documentation change, particularly in the tutorial, would help greatly.


It might make a nice example for the tutorial. However, I really don't think I ever want XOM to resolve catalogs by default. How would it even know which catalog to pick? I seem to recall the Walsh code or perhaps libxml does something with system properties or default file names in the current working directory? Ugly, confusing, error prone, and hard to debug. When XOM does implement catalogs I'm fairly sure the client code will need to explicitly identify the catalog file to the Builder.

The Walsh code uses system properties (xml.catalog.files for the ordered list of catalogs to use) or a fixed properties file on the classpath (CatalogResolver.properties), but is unable to "inject" itself because neither SAX nor JAXP (nor any other of the XML-related factory APIs) handles the catalog concept..

The result is that you have to call setEntityResolver() on the parser, which is perfectly reasonable for toy examples, but next to impossible when the parser is embedded in a library, as is the case with XOM. The helpers make it possible in some cases, as in the code I'm using, but they are poorly documented and you have to figure out how to integrate them yourself.

Unfortunately, I can't think of a clean way to "tell" XOM to use the catalog other singleton-style techniques that you're obviously avoiding or cluttering up Builder's already dense set of overloads. The least intrusive, which is in keeping with the style of handling the choice of parser, would be to poke around for the "xml.catalog.files" system property or the "CatalogResolver.properties" resource on the classpath. This way a naive user wouldn't get catalogs without taking explicit action, although it is coupled to the CatalogResolver implementation. Not pretty.

That's why I though it would be nice to have a sample of how to do it in the docs/tutorial or some sort of "contrib" section (manual Jaxen integration would be another thing to put there). The two lines of code I posted and a short paragraph would do the trick.

Michael Abato





Archive powered by MHonArc 2.6.24.

Top of Page