Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Consider adding Builder.getXMLReader()

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: John Cowan <jcowan AT reutershealth.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Consider adding Builder.getXMLReader()
  • Date: Fri, 10 Oct 2003 17:18:43 -0400

At 5:02 PM -0400 10/10/03, John Cowan wrote:

Why not? Granted, such a parser will not pass the test suite, but
it may have utility in appropriate circumstances. If you are trying
to process documents from a variety of sources that come in over the
transom with possible external subsets, which you do *not* wish to
depend on, then turning off external subset loading is very sensible.
You may fail to get the default attributes that the author expected,
but the documents will at least be processable.

It's more than that it will not pass the test suite. The biggest issue is that XOM, like XPath, assumes that all entity references have been expanded, period. It has no support for skipped entities, and that's a deliberate design decision. Off the top of my head, I'm not even sure what would happen if a parser called skippedEntity. Probably, nothing and the entity would silently vanish (a bad thing, IMO). However, it might corrupt the build or toss an exception that shuts down the entire program.

In some circumstances, speed is simply more important than conformance
to the last detail of the XML Rec. XOM should not make the use of fast
buggy parsers impossible.

I simply disagree on this point. If it's buggy, it's broken. Doing the wrong thing a thousand times faster is not helpful.
--

Elliotte Rusty Harold
elharo AT metalab.unc.edu
Processing XML with Java (Addison-Wesley, 2002)
http://www.cafeconleche.org/books/xmljava
http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA




Archive powered by MHonArc 2.6.24.

Top of Page