As for the XML attributes, DdlUtils generates attributes only if the length of the textual representation of the attribute's value does not exceed 255 characters and it does not contain characters that are illegal in XML (e.g. \0).
As for the <![CDATA[ ]]> section, assume we have an object read from the database with two attributes value1 and value2, both containing this XML snippet:
<?xml version="1.0" encoding="ISO-8859-1"?><test><![CDATA[some text]]></test>
When written by DdlUtils to a data XML file (and I forced DdlUtils to write value2 to a sub element rather than an attribute), this will look like this:
<?xml version='1.0' encoding='UTF-8'?>
<test id="1" value1="<?xml version="1.0" encoding="ISO-8859-1"?><test><![CDATA[some text]]></test>">
<value2><Unable to render embedded object: File ([CDATA[<?xml version="1.0" encoding="ISO-8859-1"?><test><) not found.[CDATA[some text]]]]><![CDATA[></test>]]></value2>
(which parses fine in a standards-compliant XML parser).
The interesting part here is that an XML parser does not care about the beginning of the embedded CDATA part, but only about the end of it. And if you look at the above, then the two brackets of the end of the embedded CDATA section are contained in a different 'real' CDATA section than the '>' character. Hence, parsing poses no problem because the ]] and the > are not seen as belonging together and thus won't end a 'real' CDATA section prematurely.
Now, if you have a case where this does not work, then that would be a bug, in which case please attach e.g. database schema and data export using for instance INSERT statements, to this issue and I'll fix it.