You should pay no attention to the fact that its in CDATA. All that means is that angle brackets should be considered to be escaped; CDATA has the same semantics as plain text included in the document with angle brackets written as < and >.
In other words the section in CDATA will appear as a simple string, by design. Thats what CDATA is for. You need to get this string, and then in turn feed it to an XML parser.
Of course, embedding escaped markup in XML is a bad idea (see even more on that); if you have any say in the design of the format, you should ask that it not be done.
Makeshifts last the longest.
Don
WHITEPAGES.COM | INC
Everything I've learned in life can be summed up in a small perl script!
The point is that ]]> and <foo> mean exactly the same thing. If you need to treat them differently, some piece of software in your chain is broken. (Yes, that means serving XHTML as HTML is broken.)
CDATA is a shortcut for when text contains a lot of literal angle brackets and carries no further meaning.
Makeshifts last the longest.
Don
WHITEPAGES.COM | INC
Everything I've learned in life can be summed up in a small perl script!
There are many many good articles and discussion threads out there that discuss this same (or similar) scenario.
for example: this thread and this excellent article by tmoertel
Youre not giving me enough information to understand what the problem is and which constraints you need to honour, Im afraid. Can you explain in more detail?
Makeshifts last the longest.
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.
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.
Makeshifts last the longest.