Well, it doesn't seem too terrible at first glance. They have the
fix for XML-Commons defect #4129, but not for defect #4130.
Do you have a proposal w.r.t. the XMLReaderFactory comment:
* <p><strong>Note to Distributions bundled with parsers:</strong>
* You should modify the implementation of the no-arguments
* <em>createXMLReader</em> to handle cases where the external
* configuration mechanisms aren't set up. That method should do its
* best to return a parser when one is in the class path, even when
* nothing bound its class name to <code>org.xml.sax.driver</code> so
* those configuration mechanisms would see it.</p>
Sounds like some decision needs to be made for Xerces in this regard.
I am somewhat concerned with the light-hearted reference to "doc
bugs". People have generally considered the SAX2 JavaDoc to be
the "gospel" when it comes to what the implementation is supposed
to do. Changing some of those comments to add, remove or change
the behavior of SAX is not something I am happy about without some
more background on who reported these supposed bugs...
Some examples are:
In DTDHandler.notationDecl:
Old:
* If a system identifier is present, and it is a URL, the SAX
* parser must resolve it fully before passing it to the
* application through this event.</p>
New:
* When a system identifier is present, applications are responsible
* for knowing if it is used as a URL, and absolutizing it against
* the appropriate URI when appropriate.
In InputSource:
Old:
* <p>An InputSource object belongs to the application: the SAX parser
* shall never modify it in any way (it may modify a copy if
* necessary).</p>
New:
* <p>An InputSource object belongs to the application: the SAX parser
* shall never modify it in any way (it may modify a copy if
* necessary). However, standard processing of both byte and
* character streams is to close them on as part of end-of-parse cleanup,
* so applications should not attempt to re-use such streams after they
* have been handed to a parser. </p>
I am not trying to argue for or against these changes, but to raise some
awareness to the fact that changes to SAX need to be taken seriously.
-Glenn
Edwin Goei
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
om> cc: [EMAIL PROTECTED],
"[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>
10/17/2001 Subject: New SAX2 release out
08:19 PM
Please respond
to
xerces-j-dev
Hi all,
There is a new SAX2 release out. Checking this into xml-commons and
other projects that use SAX could fix reported bugs. I'd like to
propose that this gets integrated into xml-commons and other projects
such as xerces 1, xerces 2, and xalan 2. Comments?
-Edwin
----- Message from David Brownell <[EMAIL PROTECTED]> on Wed, 17 Oct 2001
16:29:46 -0700 -----
To: [EMAIL PROTECTED],
[EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: [Sax-announce] SAX2 r2 pre2 release
There's a new SAX2 release available for download, see
http://sax.sourceforge.net
Or jump directly to the downloads page
http://sourceforge.net/project/showfiles.php?group_id=29449
See the release notes. Think of it as "SAX 2.0.1 beta2";
it's got no API changes, but includes fixes for all the bugs that
have been reported. A fair number of those were doc bugs,
but not all.
The release is in the form of a JAR file that includes source,
javadoc, and a pre-built "sax.jar" file.
What I'm looking for with this release is reports of problems
that would prevent this code from becoming "SAX 2.0.1";
as well as any other bugs that haven't yet been reported.
- Dave
_______________________________________________
Sax-announce mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sax-announce
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
