Hi,

I'm working on an application where we let users upload XML documents which get saved to the DB. I enclose the entire XML within a Cdata section as follows.

<document>
<name>abc</name>
<docXML>
<![CDATA[
<hello>abc</hello>
]]>
</docXML>
</document>

The problem is that the user might have a Cdata section in his XML. eg:
<document>
<name>abc</name>
<docXML>
<![CDATA[
<hello><![CDATA[ abc ]]></hello>
]]>
</docXML>
</document>

This causes my app to fail since sequence ]]> is not allowed within a Cdata. Could you please suggest on how to get around this problem ?

Thanks.

>Could you please suggest on how to get around this problem ?

Don't misuse CDATA in this way. CDATA means "character data" (as opposed to markup). Putting "<hello/>" in a CDATA section is saying "this might look like XML but actually it isn't". Which in your case, is a lie.

XML is designed to allow hierarchic nesting of elements within elements - use it that way.

Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer's Reference

But, Mr. Kay, he says that he allows people to *UPLOAD* their XML, so he doesn't have control of what they give him.

Now, personally, if he's saving their upload to a DB, I don't get why he *needs* to enclose their upload inside his own XML, but...

Only solution I could see offhand would be to encode the upload before stuffing it into his own XML and then decode it on extraction. He'd have to build a custom encoder, most likely, but it wouldn't be difficult.

Hmm??

Oh, never mind! Silly me. I get it now.

If the stuff the user uploads *IS* valid XML, then he doesn't *NEED* to use his OWN CDATA to enclose it!

So validate the upload to ensure it indeed is legal XML and then just dump it in unscathed.

DOH. Sorry about that.

Hello,

I do agree that I shouldn't be using CDATA to enclose the XML but the problem is that I'm using an existing application to save the XML to the DB. The existing application requires me to give it the XML as a chuck of data. Behind the scene it treats the contents of the <docXML> element as a string and stores it as a LOB in the DB. One of the acceptable ways is to enclose it within a CData. I dont need to worry about well formedness(those checks are performed prior to enclosing it in a CData). I just have to get it to the DB.

Thanks !

Still not clear to me why you need to shove XML inside of XML just to get XML into the DB. Are you storing the *OUTER* XML in a DB??? If so, why?

But as I first said, you could build a custom encoder that would un-XML-ize the user's XML and then have a matching decoder to re-XML-ize it.

Well, I have simplified the example. There is a lot of other information that accompanies the inner XML, hence I enclose all the information in an XML and give it to the backend code which saves it to the DB.

Can only fall back on prior suggestion.

It wouldn't be hard to un-XML-ize the users data with a simple encoder. Probably don't have to encode all that much. Might be enough to encode the CDATA delimiters.

Yes, you have to then decode it before you store it in the DB, one assumes. But if you control both ends, that shouldn't be hard.