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=10715>. 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=10715 XSLTC generates invalid XML (with output method set to xml). [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|Other |Medium ------- Additional Comments From [EMAIL PROTECTED] 2002-07-15 21:12 ------- Derek, here is what the guys responded when I asked them if this might still be a problem given the extensive reworking of the output system they did. > I think this should be because we no longer have TextOutput.java > (actually it is still there, just not used). I traced the code fragment > mentioned in the email (case '\u00a0' ) to 2 occurrences: > > case '\u00a0': > was found in file './runtime/output/StreamOutput.java' . > ---------------------------------------------------------------- > case '\u00a0': > was found in file './runtime/TextOutput.java' . > > The code now is used in StreamOutput.java only (TextOutput not used)- > and the email refers to this code being a problem when used in the html > or xml case; now that we separated the output code this 00a0 escaping > is only done in the stream case, so I think we are ok. > > Santi? What do you think? I'm not sure if we still have this problem or not, but we should definitely tell Derek to try the latest version with the new output system. From now on, TextOutput and DefaultSAXOutputHandler are "deprecated". But if you are using our native API, you may require a little help making changes for the new output handler
