How to avoid CDATA prefixed in response. REST service

[dileep keely]

REST service..
I have the xml content as CLOB in database and I need to send it to the rest client. I have corresponding element whose data type is defined as String. <xsd:String> in schema to which
I will be mapping the CLOB data obtained from DB.
I am able to map the CLOB data to xsd:String data type, but CDATA[] would be prefixed to the response when marshalled by JAXB during conversion which is the usual behavior.
But clients don't want the CDATA to be present while sending the response.
<CDATA[
<ns1:updateDetails>
<address>
</address>
</ns1:updateDetails]]>


Could you please suggest me how should I resolve.

[Paul Clapham]

You should resolve that by educating the clients. CDATA is a perfectly respectable XML construct and it's widely used in circumstances like this, where the alternative would involve massive amounts of character escaping. And any compliant XML parser will be able to handle a CDATA section correctly.

[dileep keely]

Thank you Paul,

Could you please let me know the best way that the clients can Unmarshall the XML data which has xml elements inside CDATA section(Whose xsd: type element in String in my case)..
Example:
<service><test1>test</test1> <CDATA[<test2>test2</test2 <test3>test3</test3>>]></service>

Would it be like splitting the <test1> a part and the test2 and unMarshal those elements in CDATA.

Because from the client end they want the elements in CDATA section to be Unmarshalled to respective JAXB Objects. Not the complete CDATA to String Object.

In case of any best parsers Please let me know I will research more mean while.

[Paul Clapham]

The CDATA section is simply a text node of the XML document it's embedded in. So your client would extract that text node (using any compliant XML parser) and then pass its contents to whatever the unmarshaller is. (If they can't do that, then they wouldn't be able to do it if you'd replaced the CDATA section by the equivalent text with the XML escaping rules applied anyway.) That's assuming that the CDATA section contains whatever is needed for the unmarshalling process, that is. If it's the containing document which is supposed to be unmarshalled, then the result is going to be some structure in which there's a string containing something which looks like XML. But of course given your example there's no way for us to guess which is the case.

As for finding a good parser, if you're working in Java then you're unlikely to find non-compliant parsers unless you work hard to find one. Just use a parser which is already built into Java.

[William Brogden]

That sounds sort of like a problem a client once handed me.

Due to a string of questionable design decisions, the working XML document contained CDATA sections of text where the text was a complete XML document. The extracted text had to be parsed as a separate document, which was of course unrelated to the schema of the containing document.

Lots of custom programming work but entirely possible.

Bill

[dileep keely]

As the complete xml was stored at our end my idea was to map it the <xsd:String> in schema.
Our team and clients is not listening to my suggestion .,So Im modifying the schema design from <xsd:String> to relavent elements corresponding to the XML elements (clob in Database).
Then I would pull xml data from DB and Unmarshal it and then Marshal it back while sending response to client..
I think its a weird way as we already have the xml data and we are playing back and forth but Im with no luck..

Thanks Paul and Bill.