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=5085>. 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=5085 Reporting of externally specified encodings ------- Additional Comments From [EMAIL PROTECTED] 2001-11-27 10:21 ------- >If the parser isn't ever using an externally specified encoding, then I would >suggest that is a bug in the parser. Yes, that is the case. The current code uses: InputStream stream; stream = new URL(expandedSystemId).openStream(); It then auto-detects the encoding. It seems like it should be using something like: InputStream stream; URLConnection conn; conn = new URL(expandedSystemId).openConnection(); if (encoding == null) encoding = conn.getContentEncoding(); // or is it getContentType? stream = conn.getInputStream(); definitely something to look into. Otherwise, I guess I am still not sure if there is a problem. The startDocument/startEntity events pass the actualEncoding property and the xmlDecl/textDecl events pass the encoding property. I do not see where the need for a boolean comes from. Also, I disagree with the comment about falling back to the encoding property. The actualEncoding property should never be null. I am also not sure that there is an issue with entity resolvers. I was not suggesting that we would not report the actual encoding in that case, just was pointing out that the parser was reporting a piece of information to the application that "from the parser perspective" was provided by the application. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
