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: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • To: Michael Abato <mrabato AT earthlink.net>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] URI (and question re: catalog resolvers)
  • Date: Tue, 6 Apr 2004 11:10:10 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page