Re: CDATA in an XML file for parsing.

[dimar]

You will do well to consider the admonition made earlier by Aristotle. If you find yourself tempted to reach for the 'CDATA' or 'entity-escaping' key-combination in your text-editor or IDE, do not do it unless and until you have given serious consideration to alternatives.

Such as:

• apply base64 encode and base64 decode
• supply a link to the external (non-well-formed) resource

If you have control over the generation of the content, there is no excuse why you should not at least *consider* the alternatives.

If you do *not* have control over the entire content, it is all the more reason to consider the woes of naively tossing around CDATA and escaping.

• What if the content itself contains a 'CDATA' section that is intended to be displayed as an example of how to make a 'CDATA' section?
• What if the content contains (ampersand)nbsp; that is intended to demonstrate the symbol used to represent blank space (and not intended to be rendered as an actual blank space)?
• What if the content contains typos that just coincidentally happen to look like codes in your escaping mechanism?

There are many many reasons why escaping and CDATA is often a bad way to go. This badness is exactly why perl has 'quotelike operators' and why MIME has 'multipart boundary delimiters'. XML has neither of these, so often people resort to CDATA and escaping, even when that is *not* the best, (or even a good) way to go.

[Aristotle]

Note that these “What if” questions all have unambiguous answers; any ambiguities result from buggy software, not from the XML spec. The reason for avoiding escaped markup within CDATA is not that it causes ambiguities in the data, but the many difficulties embedded markup causes for processing and that the well-formedness guarantee you get by using XML is thrown out of the window.