XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

At 8:54 AM -0400 4/6/04, Michael Abato wrote:

> This leads to one issue I have with XOM, which is that it doesn't handle
> catalog resolvers very elegantly. (It comes up here, because using getResouce
> means the parser doesn't (necessarily) have base file to resolve relative
> url's relative to, leaving you with only absolute url's for entities - unless
> you implement a catalog resolver).

XOM does allow you to set the base URI on a document if you're 
building it from an InputStream. I do not think catalog resolvers are 
the right solution to this problem. In fact, they're vast overkill 
for what can be fixed with a simple call to setBaseURI().

That said, catalogs are a good thing in general, and are on my Todo 
list for explicit integration in XOM sometime after 1.0. If there's 
something in XOM now that prevents them from being used with Walsh's 
code, then it needs to be fixed.

> If you want to use a catalog to resolve entity references (dtd's, external
> entities), which is a "good thing" (the classic Norm Walsh article 
> is currently
> at http://xml.apache.org/commons/components/resolver/resolver-article.html),
> then you need to specify the parser explicitly, e.g.:
>
> XMLReader reader = new org.apache.xml.resolver.tools.ResolvingXMLReader();
> Builder builder = new Builder(reader);

Doesn't look too hard. The only tricky bit is that this would prevent 
XOM from using the much faster NonverifyingFactory. However, possibly 
I could special case that. It shouldn't affect the public API at all.

> While this solution is wonderfully for a mature system, but is quite a leap
> for anyone other than an XML wonk. (This is as much to do with how the
> fact that entity resolution is underplayed in the XML spec and  and only
> the obvious implementation 
> [http://xml.apache.org/commons/components/resolver/index.html]
> is "buried" at apache as it does with XOM et. al.)

The Commons web site needs serious work.

> This means that you lose the nice touch of XOM finding the best parser
> for the job, and that upgrading XOM and/or your XML parser can be quite
> frustrating, particularly if you need to used the "endorsed" 
> libraries mechanism,
> which you do in a servlet context.

I don't think XOM should be using catalogs unless the user explicitly 
requests it, and knows what they're getting. As I said, I've thought 
about APIs for this and may merge it into Builder post-1.0; something 
like a setCatalog(Document catalog) method in  the Builder class. 
This may or may not be based on Walsh's implementation. But I don't 
want to delay 1.0 for that.

> 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.

--

  Elliotte Rusty Harold
  elharo AT metalab.unc.edu
  Effective XML (Addison-Wesley, 2003)
  http://www.cafeconleche.org/books/effectivexml
  http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA