Michael Glavassevich wrote:
Out of curiosity, aside from the obviously bad default for namespace awareness what other pitfalls are there?
That's certainly the biggest problem in practice. Beyond that, the SAXParser class has a lot of parser methods that depend on SAX1. The use of the DefaultHandler adapter class instead of the individual interfaces severely restricts its flexibility. For instance, I can't easily use my custom ContentHandler with someone else's EntityResolver. It's just an all around ugly design.I'm also not happy with the decision to throw UnsupportedOperationExceptions from a getter method. isXIncludeAware should simply return false if the underlying implementation doesn't support XInclude. Ultimately, of course, this whole approach of adding new methods to support new features isn't scalable or flexible. It requires a major spec rev just top add one new experimental feature. The SAX2 approach of named features and properties is far more extensible and scalable. SAXParserFactory is API bloat that's still expanding.
Some of the ugly design, especially the bit about using DefaultHandler instead of the interfaces, is rationalized by J2ME considerations. However, this is just another effect of the "One true API" myth. An API that is tailored for micro-environments may well not be suitable for the desktop and server environment, and vice versa. Nor is it often necessary that applications be ported between them. It is better to have individual APIs and libraries that fit their target environments rather than trying to make one API/library fit everywhere.
-- Elliotte Rusty Harold [EMAIL PROTECTED] XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
