XOM API for Processing XML with Java

[Michael Abato <mrabato AT earthlink.net>]

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