My memory is a little hazy, but I definitely had a problem with this which I finally got around using this code fragment:
t[#t + 1] = '<![CDATA['
for line in file:lines() do
t[#t + 1] = line
t[#t + 1] = ']' .. ']>' -- ********** this being the key line.
I concluded the problem was with the lua parser itself (or maybe the way Lightroom calls it?), since the errors I was getting had to do with correct interpretation of the lua file itself, not the xml generation per se.
Once separating the CDATA closure string I was able to use LrXml to build the CDATA into an xml file without any more problems.
Hope this helps, and please let me/us know if it does or does not - thanks.
The double square bracket closing the CDATA section was never a problem. I had issues with LrXml encoding the opening angle bracket as an < entity:
local xml = LrXml.createXmlBuilder(false)
local strXML = xml:serialize()
Produces the following maligned XML:
I guess one way to go about it is to run serialized XML through string.gsub to un-encode the "<![CDATA[" sequence as follows:
strXML = string.gsub(strXML, "<!%[CDATA%[", "<![CDATA[")
This is a nasty workaround, but this appears to be the only way to get the job done. Now my serialized XML looks as expected:
This only leaves me wondering as to why LrXml doesn't support CDATA sections through its API, they are not that uncommon...
Yes - my memory is coming back to me - I too had to do the same thing as you - sorry, I missed it last time around.
In fact, I submitted a bug report / feature request about it - shortly after SDK 2.0 was released. Hard to imagine why that fell through the crack between SDK2.0 and SDK3.0 - its a pretty glaring ooooooops...
I try to give Adobe the benefit of the doubt, but when stuff like this persists I can't help but scratch my head...
I do think we can use the official bug-report form for SDK bugs as well - I suspect Adobe takes them more seriously than bug reports in the forum. I think this qualifies...