Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] dtd problems

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: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] dtd problems
  • Date: Mon, 20 Sep 2004 09:15:09 -0400

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.





Archive powered by MHonArc 2.6.24.

Top of Page