Bug 958343

Summary: XML Entities in CDATA are being resolved
Product: [Community] Publican Reporter: Lee Newson <lnewson>
Component: publicanAssignee: Jeff Fearn 🐞 <jfearn>
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.1CC: aigao, jfearn, rlandman
Target Milestone: 3.2   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 3.2.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-09 04:48:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Example Book none

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:

&amp;
&apos;
&nbsp;
&quot;
&mdash;

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