Re: Info on serializer property

Play the video

Subject: Re: Info on serializer property
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 29 Jan 2013 12:39:35 -0500

At 2013-01-29 17:53 +0530, karthikeyan.sd@xxxxxxxxxxxxx wrote:

We are experiencing an issue with xml serializer after upgrading to WAS7
from WAS6.[IBM websphere]

We are serializing the XML file using below code which converts CARRIAGE
RETURN to &#13; in WAS7 within CDATA section of an element.

Code:

            Properties props =
OutputPropertiesFactory.getDefaultMethodProperties("xml");
            props.setProperty("omit-xml-declaration", "yes");
            Serializer serializer = SerializerFactory.getSerializer(props);
           serializer.setWriter(writer);
       serializer.asDOMSerializer().serialize(doc);

Example:

WAS6:

<MsgTyp><![CDATA[other
Document]]></MsgTyp>

WAS7:

<MsgTyp><![CDATA[other]]>&#13;<![CDATA[
Document]]></MsgTyp>

Can anyone please assist us on how to get this fixed?

Consider that in XML processing an input end-of-line sequence is always normalized to simply a LINE FEED (LF):

  http://www.w3.org/TR/2008/REC-xml-20081126/#sec-line-ends
  "To simplify the tasks of applications, the XML processor MUST
   behave as if it normalized all line breaks in external parsed
   entities (including the document entity) on input, before
   parsing, by translating both the two-character sequence #xD #xA
   and any #xD that is not followed by #xA to a single #xA character."

So it looks like your WAS7 problem is on the input side of the system, not the output side. It looks like WAS6 was correctly interpreting end-of-line normalization in XML by throwing away the CR and converting CR-LF to simply LF.

But it means WAS6 never was preserving your CR ... it was properly converting the CR-LF to LF.

Your evidence is that WAS7 is not performing the end-of-line sequence translation on the way in, thus the internal data set contains the CR that should have been tossed out. The CDATA serialization is preserving that CR.

We are badly affected because of this.Awaiting your response

Talk to your supplier about the failure to abide by the XML rule cited above for input end-of-line-sequence normalization.

I hope this helps.

. . . . . . . . . Ken

p.s. this isn't an XSLT problem (though you may not have recognized that) so this isn't really the right forum

--
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Current Thread
Info on serializer property karthikeyan . sd - 29 Jan 2013 12:23:44 -0000 Message not available G. Ken Holman - 29 Jan 2013 17:39:54 -0000 <=

<- Previous	Index	Next ->
Info on serializer property, karthikeyan . sd	Thread
Re: [xsl-fo] Flexible Region-, G. Ken Holman	Date	Re: [xsl-fo] Flexible Region-, Geert Bormans
	Month

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Subscribe in XML format

RSS 2.0
Atom 0.3

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >