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=22623>.
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=22623

Tabulator (U+0009) character in element attribute not serialized as numerical entity 
by default xml serializer





------- Additional Comments From [EMAIL PROTECTED]  2003-08-25 16:30 -------
Brian,

that is exactly what I am asking for, and I think it is the correct way to serialize 
an element's 
attribute to an XML character stream so that when subsequently parsed by a conforming 
parser (see 
the XML spec on attribute normalization rules), the _internal_ tree representation is 
the same as 
before serialization. Actually, that is the key issue here.

>but there is a little bit of code in writeAttrString() that checks of the 
>carriage-return and new-line are adjacent, and if they are then it only writes 
>out a single new line (as it would in writing out a character node).

I think this behaviour is wrong for attributes. Such a processing already will have 
been done at 
parsing time (be it the XSL or XML file) due to the normalization rules, meaning that 
if the serializer 
sees a CR/LF combo in the internal attribute value in the document tree, then it is 
there on 
purpose. Therefore this combo also needs to be written as two separate numerical 
entities, IMO.

Please correct me anyone if my logic/reasoning is wrong!

Note: This is "only" a user's report; I am not at all fluent with Xalan's internals 
and its code and 
therefore will probably not be able to help actually fixing the code - sorry.

Regards, Christian.

Reply via email to