Bug 958343 - XML Entities in CDATA are being resolved
Summary: XML Entities in CDATA are being resolved
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: 3.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: 3.2
Assignee: Jeff Fearn 🐞
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-01 01:54 UTC by Lee Newson
Modified: 2013-08-09 04:48 UTC (History)
3 users (show)

Fixed In Version: 3.2.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-09 04:48:15 UTC
Embargoed:

Attachments (Terms of Use)
Example Book (10.00 KB, application/gzip)
2013-05-01 01:54 UTC, Lee Newson 		no flags Details
View All

Description Lee Newson 2013-05-01 01:54:09 UTC 
Created attachment 742064 [details]
Example Book

Description of problem:
XML Entities that are used in CDATA blocks are being resolved and replaced. Since CDATA is meant to be unparsed content, these should not be resolved and should be left as is. I've tested this with the following XML Entities, though I imagine it would happen with any entities:

&
'
 
"
—

Version-Release number of selected component (if applicable):
3.1.5

How reproducible:
Always

Steps to Reproduce:
1. Create a book with a <programlisting> that contains a CDATA element.
2. Build the book.
3. Inspect the <programlisting> code.
  
Actual results:
The XML Entities in the CDATA element are being resolved and replaced.

Expected results:
The XML Entities should not be resolved and replaced.

Workaround:

When putting XML Entities into CDATA, ensure that the ampersand of the entity is replaced with &amp;. Eg &qout; would become &amp;quot;

Additional Information:

I've attached a simple book that contains a single chapter with a <para> and a <programlisting> that contains some CDATA with an XML Entity.
Comment 1 Lee Newson 2013-05-01 02:01:39 UTC 
Forgot to mention I've tested this on RHEL 6.4 and Fedora 18 (using the builds in the testing repo), using the latest updates available at the time of submitting this bug.
Comment 2 Jeff Fearn 🐞 2013-05-16 23:07:49 UTC 
A better workaround is to follow the instructions on using the extras directory at http://jfearn.fedorapeople.org/en-US/Publican/3.0/html/Users_Guide/chap-Users_Guide-Creating_a_document.html#sect-Users_Guide-Adding_code_samples
Comment 3 Jeff Fearn 🐞 2013-07-15 04:03:08 UTC 
Modified XML::TreeBuilder to support cdata, pushed upstream.

Updated Publican to support new XML::TreeBuilder functionality. Bumped XML::TreeBuilder dep to version 4.2.

To ssh://git.fedorahosted.org/git/publican.git
   de69890..783564d  HEAD -> devel
Comment 4 HSS Product Manager 2013-07-16 03:47:51 UTC 
HSS-QE has reviewed and declined this request. QE for this bug will be handled by IED.
Comment 5 Tomas Capek 2013-07-22 13:42:43 UTC 
Seems to work:

$ rpm -q publican
publican-3.1.5-0.fc19.t62.noarch

sample code: 

<programlisting>
<![CDATA[
   &amp;
   &apos;
   &nbsp;
   &quot;
   &mdash;
]]>
</programlisting>


rendered after build as:

			
   &amp;
   &apos;
   &nbsp;
   &quot;
   &mdash;
Comment 6 Jeff Fearn 🐞 2013-08-09 04:48:15 UTC 
The fix for this bug has been shipped in publican 3.2.0
Note You need to log in before you can comment on or make changes to this bug.