Re: XML-INTO, CDATA, and multiple spaces

Yeah, I hear you. But I've seen different interpretations. Here are a couple statements from a developerworks article - these refer to the material between the CDATA markers.

"Anything between those bits of markup will pass through the XML parser untouched."

and

"In either case, the contents of the CDATA section will be available without modification."

That's kind of what I had thought. It might be a misinterpretation on the part of the authors, too. The article is at -

http://www.ibm.com/developerworks/library/x-cdata/

On the other hand, the W3 spec on CDATA doesn't mention spaces, it speaks of using CDATA "...to escape blocks of text containing characters which would otherwise be recognized as markup."

BTW, this XML is coming TO me from someone else.

There is some attribute called xml:space - but I don't have control of the markup until I get it.

I chose not to use the trim=none option, because there are also newlines in a <history> tag - we are bringing this data into a physical file on our system and a fixed-length text file for the mainframe here. I will give it a try, as it may not matter if newlines are preserved.

I do think my best choice is to encode these spaces - we do need them. That is, if trim=none is not working as we want it to.

Thanks, and see you in a couple weeks.

Vern

On 9/20/2013 2:20 PM, Scott Klement wrote:

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