Re: XML-INTO, CDATA, and multiple spaces

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