Re: SAX2: When to resolve System Ids

> "Karl Waclawek" <[email protected]> wrote on 03/31/2004 12:30:03 AM:
> 
> > 
> > > When I raised this a couple weeks ago, it got lost (possibly because 
> these 
> > > threads are getting fragmented between sax-devel and xml-dev) in the 
> > > discussion on the canonical location for feature documentation. Either 
> it 
> > > was always intended that the systemId passed to 
> > > DeclHandler.externalEntityDecl() be fully resolved or including this 
> > > method among those affected by resolve-dtd-uris is an error.
> > 
> > For now I have decided to implement it like the feature 
> > documentation suggests,
> > as I fail to see why externalEntityDecl() should be treated differently.
> > Maybe I am overlooking something obvious.
> 
> Two words... backwards compatibility.

For the .NET port this is less of an issue, of course.
To which degree would this incompatibility be a problem
in the real world? In the .NET world, for instance,
if you pass a "relative" and base URI to the Uri class
for absolutizing the relative Uri, it will simply ignore
the base Uri if the relative Uri is already resolved.
Does it work the same in Java?
 
> I believe the text in DeclHandler.externalEntityDecl() predates this 
> feature. It says that systemId is the 'declared' system identifier. Xerces 
> for instance reports the declared system identifier as it was specified in 
> the document to DeclHandler.externalEntityDecl(). It reports an absolute 
> URI for DTDHandler.notationDecl() and DTDHandler.unparsedEntityDecl(). 
> It's what the javadoc says. I agree this doesn't make much sense, but 
> changing the behaviour for DeclHandler.externalEntityDecl() now has the 
> potential to affect users of SAX who rely on this parameter being the 
> specified system identifier and not the one absolutized against a base 
> URI.

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)

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, [email protected]
See:  http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel