|
We need to allow people to view/edit XML messages
in our application. When we import a document that has a CDATA section
into an XML Parser the values are converted
using the escape characters and created in the DOM as a text node. (We
have tried this with 2 parsers, Sun Forte 4GL and Oracle's Java Parser) Thus, if
the document is exported from the DOM, the CDATA section is gone, and the data
now contains the escape characters.
Example Starting Doc
<aDoc><![CDATA[<aTag>Hello</aTag>]]></aDoc>
Example Ending Doc
<aDoc><aTag>Hello</aTag></aDoc>
I am sure this is the intended DOM behavior,
but it clearly does not satisfy our
needs.
Note: If we add a CDATA section
programmatically using the DOM, the export is correct. This leads us to
our only proposed solution so far which is to write our own code that parses the
document and creates a DOM representation of the data not converting the CDATA
sections. Hopefully this is not the only solution!
Here is the code we are using (This is using the
Sun Forte 4GL but you should be able to read this for the logic.):
//Open a Test
File
aFile:File=New; aFile.SetLocalName('c:\\temp\\ainfile.xml'); aFile.open(sp_am_read); //Import the
document
aDocument:Document=New; aDocument.ImportDocument(aFile); //Create an output
file
aOutFile:File=New; aOutFile.SetLocalName('c:\\temp\\aoutfile.xml'); aOutFile.open(sp_am_write); //Export the
docuemnt
aDocument.ExportDocument(aoutFile); //Close the
files.
aFile.close(); aOutFile.close(); I remembered this sort of question
occuring on the list in June and looked in the archives but the solution
was encoding base64 and that won't work for me. What really scares me is
in the archive thread Tim Bray says " I'm always happy to avoid using CDATA
sections if I can."
Lynda
VanVleet
Lynda Van Vleet |