XOM API for Processing XML with Java

[Elliotte Rusty Harold <elharo AT metalab.unc.edu>]

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.

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.

--

  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