Re: SAX2: When to resolve System Ids

Michael Glavassevich <[email protected]> Wed, 31 Mar 2004 10:53:12 -0500
Newsgroups gmane.text.xml.sax.devel
Message-ID <OF94857835.44DF9BA7-ON85256E68.00564B2B-85256E68.005744E3@ca.ibm.com>
"Karl Waclawek" <[email protected]> wrote on 03/31/2004 09:12:30 AM:

> 
> > "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?

It's not a relative URI if it's already resolved. What if your application 
wants to use a different base URI instead of the one the parser would use? 
If the URI has already been absolutized you cannot do this.

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: [email protected]
E-mail: [email protected]