Does anyone know why this behaviour was adopted in XNI?
I chose this so that people would know the original encoding of the parsed documents. That way they could write the document back out with the same encoding.
Any thoughts on how to move forward with this? Locator2
> is still in alpha, so one would think that it should by > no means be carved in stone at this stage.
I don't think that they are "fundamentally at odds" with each other. We can fix the situation simply by modifying the documentation for startGeneralEntity's encoding paramter. Instead of stating that the encoding is always null when parsed from a java.io.Reader, we could add "unless the encoding is set on the input source". It's not really a change -- more of a clarification. :)
We would still have to work around the fact that the encoding information provided in the startGeneral- Entity call is disconnected from our own XMLLocator methods. But we can just keep track of this info in the SAX parser. It's certainly a lot easier than modifying XNI at this stage.
Whatcha think?
-- Andy Clark * [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
