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

http://issues.apache.org/bugzilla/show_bug.cgi?id=39927





------- Additional Comments From [EMAIL PROTECTED]  2006-08-02 12:15 -------
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #7)
> > > In the meantime, it looks as if there's another bug in GCJ's 'transform'
> > > package, or it's not being passed an option it requires. The generated
> > > CodePointMappings.java contains lot's of XML entities such as '&lt;',
'&gt;' and
> > > '&amp;'.  So, for whatever reason, they're not getting resolved to their
> > > respective '<', '>' & '&' characters!
> > 
> > Ouch. That's a pretty basic thing.
> 
> Well, having had a quick look at code-point-mapping.xsl and the XSLT spec at
> http://www.w3.org/TR/xslt#disable-output-escaping I think GNU's transform is
> actually conformant as there is no explicit instruction, that I can see, to 
> tell
> it to not output conformant XML.

But disable-output-escaping is for the XML output method and we're using the
text output method. And it's not the output that's wrong, I think it's the
parsing of the stylesheet that's not happening as it should. The XSLT should
internally work with unescaped characters.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Reply via email to