I thought about that too, but seems like the problem is during the node construction time, not the serializer itself.
The problem is that Xalan-J uses the text-serialize internally to construct the element node, which will convert the 0x0a to (0x0d, 0x0a) pair internally. Therefore, the attribute value I received in my sax event will contains this (0x0d, 0x0a) pair... (which I guess this already contradict to the xml text normalization rules?)
By the way, is it correct to use the text-serializer for node construction?
William.
-----Original Message-----
From: Joseph Kesselman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 12, 2003 5:03 PM
To: [EMAIL PROTECTED]
Subject: Re: Did xalan-xslt handle linefeed character in xml text...?
XML serializers generally convert the XML newline character (0x0a, LF) into whatever is the native representation on the platform they're running on, just as XML parsers will normalize most of the standard newline representations (CR, LF, CRLF, and recently NEL) into an XML newline.
If you're using Xalan-J, you could try setting your Java environment's value of the line.separator property (assuming your JVM's security manager permits that; not all do) and see if that allows you to control how newlines are written out.
If not, your best bet may be to have Xalan output to SAX and route that into your own serializer which handles this the way you want it to.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more. "The world changed profoundly and unpredictably the day Tim Berners Lee got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
