DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13202>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13202

Wrong systemId pass to EntityResolver

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID



------- Additional Comments From [EMAIL PROTECTED]  2002-10-17 15:55 -------
Hi Victor.  We should probably take detailed discussions like this to the 
xerces-j-user list; other people are more likely to follow them then, and we 
could more easily come to a consensus as to the proper state of the bug.  

A bottom line, though, is that, if a SAX parser finds a relative URI in a 
document, it has to absolutize it before handing it to the EntityResolver.  
That's what the SAX spec says, and that works well for most applications--since 
most apps deal with common URI schemes like file:// or http://.  It isn't 
always optimal though (what standard API is?)

So Xerces absolutizes the URI relative to the URI of the enclosing entity, if 
known, or to the user.dir property otherwise.  That's why I suggested setting 
the systemId on the InputSource you return from the first call:  then xerces 
could absolutize relative to something other than user.dir.  But if you want to 
use some URI scheme Xerces doesn't know about, obviously the solution won't be 
perfect for you.  

As to this "bug":  you're best bet is to file a bug or RFE with the SAX 
maintainers if you want parser behaviour changed for URI schemes the parser 
doesn't know about.  But until the spec changes, there really isn't anything 
Xerces can do to help you.  That's why I'm continuing to mark the bug invalid 
here.  

In your case though, I'm betting that by using the publicId and a bit of String-
fiddling with the systemId, you'll have no trouble getting your EntityResolver 
to do what you need it to.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to