At 8:53 PM +0100 3/5/04, Simon Pepping wrote:
It took me a little while, but I now remember again why I did not want
to use the XMLReaderFactory. I do not understand how I can guarantee
that I get an XMLReader that is capable of validation. In
SAXParserFactory I can configure the factory to look for a validating
and namespace-aware parser. In XMLReaderFactory, it may produce an
XMLReader which throws an exception when I want to set the validating
feature on it.

This is a new one for me, and I can see how you might think SAXParserFactory guarantees validation by looking at the API docs, but it isn't true. SAXParserFactory can indeed give you a parser that does not support validation. If you ask for validation, and a validating parser isn't available, then you'll get an exception, just as you would if you tried to set validation on an XMLReader returned by XMLReaderFactory that did not support validation. Most SAXParserFactory users have installed implementations that default to Crimson, Oracle, or Xerces, all of which validate, so they never notice this.

The only way to be sure to get validation is to request a known validating parser such as Xerces by name, and it's much easier to request a known parser with XMLReaderFactory than with SAXParserFactory. The latter requires you to muck with system properties and the services API, and never be to sure whether the user is going to throw some other jar file in the mix that overrides your carefully constructed code.

I remain amazed at what developers believe about SAXParserFactory that just isn't true, and what magical properties they attribute to it. I really am curious to know how these ideas took hold in the community. Possibly there was a crucial book or tutorial at some point that promulgated these mistaken ideas that I just haven't read. You know, now that I think about it that way I have a funny feeling I may know which book that was, but I'll have to wait till I get to my office on Tuesday to check.


  Elliotte Rusty Harold
  Effective XML (Addison-Wesley, 2003)

Reply via email to