[ http://nagoya.apache.org/jira/browse/XALANJ-2006?page=comments#action_56325 ] Joe Kesselman commented on XALANJ-2006: ---------------------------------------
Sanity check: Are you viewing the output as a SAX stream? If so, remember that SAX sources may break character data into multiple events for buffering reasons; it is the SAX handler's responsibility to reassemble the characters() calls into a single string if that matters to them. Also remember that several successive CDATA Sections versus a single CDATA Section is only a syntactic difference; it has no semantic meaning in XML. (Though obviously a single CDATA Section is more compact and easier for humans to read.) If you're running through our serializers... they *should* be intelligently reassembling successive CDATASections. If they aren't, we should probably fix that. > cdata-section-elements splitted multiple > ---------------------------------------- > > Key: XALANJ-2006 > URL: http://nagoya.apache.org/jira/browse/XALANJ-2006 > Project: XalanJ2 > Type: Bug > Components: Xalan > Versions: 2.6 > Environment: Windows 2000 > Reporter: Remiu Wremlokov > Priority: Critical > > when using > xsl:output with cdata-section-elements > the output within CDATA ist splitted into several CDATA sections with the > exact length of 27. This does not happen, when ]]> CDATA termination > character combination appears, but happens always. > Intention of cdata-section-elements is to preserve the input and in this way > I really need it. > I know this issue or a similar one was opened several times and closed. I > know too, that in a strict manner this is no bug, because CDATA in a > technical way is actually preserved. > But I think, the behaviour contravenes quite strictly the original sense of > cdata-section-elements: If the output is required to be identical to the > input. E.g. especially in big documents the output is cluttered up with > endless CDATA-declarations and completely unreadable. > Working probe > XML input > <root> > > <cdata-to-preserve><![CDATA[123456789012345678901234567890]]></cdata-to-preserve> > </root> > Stylesheet > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > version="1.0"> > <xsl:output method="xml" version="1.0" standalone="yes" > encoding="utf-8" cdata-section-elements="cdata-to-preserve"/> > <xsl:template match="/ | @* | node()"> > <xsl:copy> > <xsl:apply-templates /> > </xsl:copy> > </xsl:template> > <xsl:template match="cdata-to-preserve"> > <cdata-to-preserve> > <xsl:value-of select="."/> > </cdata-to-preserve> > </xsl:template> > </xsl:stylesheet> > Output > <?xml version="1.0" encoding="utf-8" standalone="yes"?> > <root> > > <cdata-to-preserve><![CDATA[123456789012345678901234567]]><![CDATA[890]]></cdata-to-preserve> > </root> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
