Re: XML-INTO, CDATA, and multiple spaces

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Vern,

CDATA is normally used so you don't have to escape special characters in 
your XML data (such as <, > and & symbols).  As far as I know, it has 
absolutely nothing to do with blanks.

I have not run a test, but...  I would never have thought or guessed in 
a million years that CDATA would stop XML-INTO from removing blanks. 
That's not what CDATA is intended for, and I've certainly never seen it 
used for that.

If you want to prevent XML-INTO from removing blanks, why don't you use 
the trim option?

-SK


On 9/20/2013 1:44 PM, Vernon Hamberg wrote:
> I have an XML file I'm processing - comes from a "partner" app elsewhere
> here.
>
> One of the nodes is our customer number, and it can contain more than
> one space, as here -
>
>       <custno><![CDATA[008_XY  00020001]]></custno>
>
> We are to expect the CDATA, since we are assuming it should tell the
> parser to leave things alone.
>
> Now is that a correct assumption? I did a little digging, and it seems
> there is some variation in interpretation.
>
> XML-INTO is what I'm using, with the default for the trim option (to
> trim all, including leading and trailing whitespace when there is more
> than one space, leaving a single space). I left it this way, because we
> also get newlines in the data.
>
> I would like to know if XML-INTO should leave things alone that are in a
> CDATA block - that seems to be generally assumed, but I can easily be
> mistaken here.
>
> My main option is to encode these particular spaces - sed should do the
> trick with a little effort. The alternative is to get the software on
> the other end to do the encoding - good luck! And some consultant would
> want us to run the PAYMNY command.
>
> Thoughts? Bug? Feature? Options?
>
> Thanks
> Vern