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: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: Elliotte Rusty Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] Consider adding Builder.getXMLReader()
  • Date: Fri, 10 Oct 2003 13:31:49 -0700

Elliotte Rusty Harold wrote:
I'm thinking about this. It's possible XOM will add something like this. However, if I do it would have to be more careful not to override the features and properties that the Builder wants set a certain way. For instance, I think your patch would allow the user to turn off loading of the external DTD subset.

Just move the

if (propertiesAndFeatures != null) { ...}

from the end (where it is now) to the beginning of setupParser(...)
That way XOM will override user specified features where XOM depends on them.

Wolfgang.


But I am seriously considering adding a feature/property interface to the Builder class that would allow setting and getting individual features, while filtering out requests to reset features and properties XOM depends on such as entity-resolution. This could allow me to remove the XMLReader argument from the Builder class thus making the public interface of the nu.xom package completely independent of SAX. This would mean in the future I could use a different non-SAX parser/API such as StAX or XNI if that seemed useful.

More immediately, it would help XOM enforce the use of Xerces, which I'm seriously considering. As the unit test suite grows, it's becoming obvious to me that most SAX parsers are seriously broken; either a little (Crimson, Xerces 2.5 and earlier) or a lot (Oracle, Piccolo). Noticing things in the XOM unit tests has even led me to find bugs in other non-SAX/non-Java parsers such as libxml. Xerces 2.6 (not yet released, get it out of Gump or the XOM CVS tree) is the *only* parser that is capable of passing the complete XOM test suite.


Minor note: On the other hand pluggable parsers might be useful for testing. If no other parsers were pluggable, one could not easily find out to what extent they work (or do not work), or if they become fixed at some point in the future. You wouldn't have found out that they have problems if they weren't easily pluggable, right?

Wolfgang.





Archive powered by MHonArc 2.6.24.

Top of Page