> > Unfortunatly, the mistake is on page 23. In the javax.xml.parsers > > documentation, we define the getParser method to throw the exception. The > > ommission on the method description is erroneous. > > Unfortunately :) Probably in version 1.1 it'll be removed. Anyway, as > long as the two descriptions are coherent, it's good for me.
We'll see. But I will endeavor to make sure that the Final Release of the spec is corrected here. > I agree with you on that, in fact, expecially when considering SAX2 > properties and features, SAXExceptions come always into play when > creating the real parser instance. But, so, if we have it in SAXParser, > we should also have it in DocumentBuilder (for simmetry). Again, JAXP > 1.1? Nah -- I don't agree that the DocumentBuilder should throw SAXException. I see the DOM and SAX classes actually diverging a bit from their initial symmetry. I don't think that we need to do strict mirroring just for the sake of such. > The only "issue" I see right now in having two implementations is that > Sun's RI will probably default to Project-X, in case no System property > is found, while mine defaults to Xerces. Given the fact that there is no > "easy" way for specifying system properties in the current JDKs up to > 1.2 (apart from command line options), depending on the JAXP > implementation you choose, you have a default parser. Yep. This is an issue that we need to hit for JAXP 1.1 (hopefully). > What I want to be able to have is to be able to compile a XML enabled > application regardeless of what parser you have in your CLASSPATH, and > then running it, again, regardeless of what JAXP implementation (and so > default parser) you have. Well, you've got that now :) Unless you cast that is to take advantage of implementation specifics. .duncan
