> Here are some possible fixes.
>
> The first (org.xml.sax.package.html.diff) drops
> DeclHandler.externalEntityDecl from the list of methods affected by the
> resolve-dtd-uris feature.
>
> The second (org.xml.sax.ext.DeclHandler.java.diff) aligns the description
> of DeclHandler.externalEntityDecl with DTDHandler.unparsedEntityDecl,
> requiring that the parser absolutize the system identifier, though this is
> backwards incompatible and may affect some real world users who expect the
> declared system identifier even if it was always intended that the system
> id passed to DeclHandler.externalEntityDecl be fully resolved.
My vote is for the second fix. Unless someone can convince me of a good reason
why DeclHandler.externalEntityDecl should be treated differently.
In SAX.NET at least, this would be preferable, as there is almost no need for
backwards compatibility.
>
> Karl had another suggestion (2004-03-31):
>
> "Maybe it could be settled this way:
>
> If the application reads or sets the "resolve-dtd-uris" feature,
> then the parser is bound by its current documentation. However,
> in its initial state the parser works as as originally documented.
> Obviously there would be no documented way to reset the parser
> to its inital state, and one would have to create a new instance
> for that purpose.
>
> This would allow legacy application to work.
> (not an elegant solution)"
Even though I made this suggestion I don't really like it.
It's a sacrifice on the altar of backwards compatibility.
Karl
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
List: sax-devel, sax-devel@xxxxxxxxxxxxxxxxxxxxx
See: http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel
|
