After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 120971 - cdata-section-elements doesn't work
cdata-section-elements doesn't work
Status: VERIFIED FIXED
Product: libxslt
Classification: Platform
Component: general
1.0.30
Other Windows
: Normal normal
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Blocks:
 
 
Reported: 2003-08-29 09:17 UTC by Steve Hay
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Steve Hay 2003-08-29 09:17:45 UTC
XSLT converts CDATA sections into text by default. I need this to not
happen, and I was informed (on the perl-xml mailing list) that <xsl:output
cdata-section-elements="..."> would do the trick. It doesn't.

Here's a simple example.  This is the identity transformation from section
7.5 of the XSLT 1.0 spec, plus a <xsl:output> element to preserve the CDATA.

stylesheet: (id.xsl)
=====
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:foo="http://foo.org">
  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>
  <xsl:output cdata-section-elements="foo:elt"/>
</xsl:stylesheet>
=====

xml input: (test.xml)
=====
<?xml version="1.0"?>
<root xmlns:foo="http://foo.org">
  <foo:elt>
    <![CDATA[>]]>
  </foo:elt>
</root>
=====

When I run "xsltproc id.xsl test.xml", here's the output:
=====
<?xml version="1.0"?>
<root xmlns:foo="http://foo.org">
  <foo:elt>
    &gt;
  </foo:elt>
</root>
=====

As you see, the CDATA section has still been converted to text.

I've tested this with 1.0.31 and CVS (as at 28 Aug 2003).  I've marked this
bug as a "blocker" because I really can't use libxslt if it doesn't
preserve CDATA sections.

Incidentally, the only reason that I'm using libxslt in the first place is
that libxml2 doesn't have any namespace normalisation support.  What I'm
actually doing is simply adding elements into an XML document that declares
a namespace in its root element.  The new elements that I add all get a
redundant namespace declaration in them which I don't want explicitly
written in -- I want them (for aesthetic and space reasons) to inherit the
root element's namespace (which is the only namespace in use anywhere in
the document).  It would be an enormous help to me to have a method in
libxml2 to do some namespace normalisation.  Even just a simple case such
as this for the time being would suffice if a more complete solution is too
hard.

Basically, I just want to be able to normalise this:

<?xml version="1.0"?>
<root xmlns="http://foo.org">
 <elt xmlns="http://foo.org"/>
</root>

into this:

<?xml version="1.0"?>
<root xmlns="http://foo.org">
 <elt/>
</root>

The "id.xsl" transformation above happens to do this for me, but I also
need CDATA sections to be preserved as such, not converted to text. 
Perhaps whatever namespace normalisation is being quietly done by libxslt
could be added to libxml2?

If you have any other solution for achieving this, as a workaround to the
bug reported above in libxslt, that would also be greatly appreciated.

Thanks,
- Steve
Comment 1 Daniel Veillard 2003-08-29 10:42:30 UTC
You cannot preserve CDATA in XSLT. You can ask an XSLT to generate
CDATA on some element content but the initial goal is impossible.

Okay, the libxslt bug is fixed in CVS, the problem was with 
namespaced elements ...

paphio:~/XSLT/tests/general -> xsltproc ./bug-129.xsl
./../docs/bug-129.xml
<?xml version="1.0"?>
<root xmlns:foo="http://foo.org">
  <foo:elt><![CDATA[
    >
  ]]></foo:elt>
</root>
paphio:~/XSLT/tests/general ->

Now concerning "namespace normalisation" the big problem is
to define it, I don't think there is a generally accepted definition
though the XML canonical support certainly has a definition for
it and implement it, but it may not be what you want.

Even removal of redundant XML Namespace declarations is not
trivial. It's doable though ... 

  I would like to close this bug as FIXED since this reflects the
current state, please reopen a request for extension bug for the
namespace cleanup option, it makes sense but doesn't have the same
priority as a blocker bug.

  thanks for the report and examples,

Daniel
Comment 2 Steve Hay 2003-08-29 13:26:01 UTC
Thanks for the quick response!  I've tried the change that you've
made, and it does indeed fix it for me.

I've raised an enhancement request (bug 120981) for the NS clean-up
business.  I raised it for libxml2 rather than libxslt, because I
think it probably makes more sense there.

Cheers,
- Steve
Comment 3 Daniel Veillard 2003-08-29 14:19:48 UTC
Yup, got it, thanks !

Daniel
Comment 4 Daniel Veillard 2003-09-13 20:48:02 UTC
  This should be closed by the release of libxslt-1.0.33,
                                                                     
          
    thanks!
                                                                     
          
Daniel