XOM API for Processing XML with Java

[Michael Abato <mrabato AT earthlink.net>]

Let's not let the issue get lost in the baiting here - we all know how 
and when to grep a CSV stream. The valid issue that is brought up is 
that external entities can block, which can easily cripple seemingly 
trivial code. 80-20 rule for non-experts suggests that this is a "bad 
thing", although the problem is with XML and/or its implementations, 
not XOM. The interesting question is whether or not XOM can and should 
compensate for this cleanly (where "clean" is defined in the Design 
Goals - http://www.cafeconleche.org/XOM/designprinciples.xhtml).

I see the problem as reducing to the lack of a well-designed entity 
resolution mechanism in XML and the XML API's for Java. The only 
mechanism provided is DocumentBuilder.setEntityResolver, a good 
implementation of which is available from the Apache XML Commons 
project, which is extremely expert-friendly but hard to use 
intelligently. Since there is no factory in the XML API's, you have to 
dig pretty deep to properly implement it. And since XOM hides 
DocumentBuilder by default (I heartily approve of this) you have to dig 
into XOM as well to implement the entity resolver with XOM, losing the 
factory method for selecting the DocumentBuilder. Again, no problem if 
you're living in this space, but effectively inaccessible to the 
non-expert user of XML.

So is this a problem for midrange user? I think it is, though it is 
generally subtle and reveals itself only at deployment time. I suspect 
that XML-based code often gets branded as flaky or worse because, much 
like multithreaded code that produces subtle bugs, naive code results 
in coupling production code to external resources (the external 
entities named by the dtd URL). The hoster of that url could change the 
url (eg: apache "promotes" the project to top level...) or their site 
is down, or just you get a "dns" glitch. Furthermore, environments for 
deploying real-world applications often don't even have direct access 
to the open internet! The resulting bug is generally obscure, involving 
long timeouts and deep stack traces through the XML API's that don't 
reproduce in development/QA environments.

What is the result? Policies that say "no DTD's". Or worse, "Don't use 
XML".

I think XOM should "do the right thing" regarding entities by default. 
I just wish I knew what that was for the 80-20 majority. I suspect it 
something like auto-detecting the apache resolver and using it by 
default, plus up-front "best practice" docs in the tutorials and 
overviews that specify a simple way to put it in place. Another thing 
that should be considered is including it (or an alternative 
implementation, if available) in the distribution. Beyond that, there 
should be a simple API for putting it in place so that the code that 
detects/selects the DocumentBuilder puts the specified resolver in 
place if possible. The biggest drawback I see to this is that it 
involves globals (of one sort or another) or cluttering the API's with 
entity-related parameters.

Michael Abato

On Sep 20, 2004, at 7:59 AM, luca wrote:

> John Cowan wrote:
>
> > In that case you need to use a parser that can be told to ignore
> > the external subset of the DTD.  (No conformant XML parser can
> > ignore the DTD altogether; the internal subset, at least, must
> > always be processed.)
>
> there must be a difference between "not ignoring a DTD altogether"
> and:
>
> - parsing the DTD URL
> - opening an HTTP connection trying to grab the DTD
> - halting everything if the DTD is not retrieved for any reason.
>
> Anyway, just to be totally clear, XML to me is just a slightly
> more standard and sophisticated way to do comma-separated lists,
> which, in a way, is all I need for my job. I think it's fair to require
> that a tool like XOM delivers out of the box
> what 'grep' has being delivering for 20 years.