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]