> From: "Glenn Marcy" <[EMAIL PROTECTED]> > > Issue 1: > > The JavaDoc for DTDHandler has an @link to > org.xml.sax.ext.LexicalHandler. > This would seem to imply that there would be a broken link if there > were a core-only SAX2 package with docs.
Javadoc warnings, no more. Just the same as when building javadoc for a core-only package without the helpers. (Yep, go back to the SAX1 overview and notice it describes them as "optional" ... :) This seems to me like a straightforward "design for the typical case" tradeoff ... and tweaking @see/@link is easy for anyone else. > Issue 2b: Resolved along with issue 2a, in the r2pre3 release. > Issue 3b: > > The comment about "standard processing of both byte and character streams" > is nothing of the sort. Assigning some sort of legitimacy to such behavior > is ridiculous at this point. No it isn't. I just ran the attached program, which reports that in fact it *IS* the standard processing for every SAX2 parser I have handy. Including AElfred2 (many versions), Crimson (1.1.3), Xerces (1.4.3, despite your comment about not closing :) and XP (0.5 still :) all do what's described there as "standard processing". Data stream handling was originally underspecified, so portable applications couldn't rely on being able to reuse streams after giving them to a parser. (The InputSource isn't modified by closing one of the streams it wraps.) After that spec update ... they still can't! So it's not as if anything changed. Closing still isn't a solid requirement, since that change was purely clarification. Parsers that for some strange reason don't close() won't immediately become nonconformant. - Dave
close.java
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
