By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,589 Members | 1,209 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,589 IT Pros & Developers. It's quick & easy.

Generating CDATA sections...?

P: n/a
Here's my problem:

<xsl:template match="/category">
....
<script
type="text/javascript">
&lt;![CDATA[
if (GBrowserIsCompatible())
{
var map = new GMap(document.getElementById("mapdiv"));
map.addControl( new GSmallMapControl());
map.addControl( new GMapTypeControl());
map.centerAndZoom(new GPoint( -4, 55), 8);

<xsl:apply-templates select="//story"/>

}
else
{
alert( "We're sorry, but your browser is not supported by
Google Maps");
}
]]&gt;
</script>
....
</xsl:template>

<!-- DO NOT reformat this. The interaction between CDATA, JavaScript
and XSL is horrible! -->
<xsl:template match="story">
<xsl:variable name="marker">marker<xsl:value-of
select="position()"/></xsl:variable>
<xsl:variable name="url">"/pres/story/article_<xsl:value-of
select='normalize-space(@article)'/>.html"</xsl:variable>
<xsl:variable name="title">"<xsl:value-of
select="normalize-space(title)"/>"</xsl:variable>
<xsl:variable name="created">"<xsl:apply-templates
select='created'/>"</xsl:variable>
<xsl:apply-templates select="location"/>
var <xsl:value-of select="$marker"/> =
createMarker(point, <xsl:value-of select="$url"/>,
<xsl:value-of select='$title'/>,
<xsl:value-of select="$created"/>);

map.addOverlay(<xsl:value-of select="$marker"/>);

</xsl:template>

<xsl:template match="location">
point = new GPoint( <xsl:value-of select="@longitude"/>,
<xsl:value-of select="@latitude"/>);
</xsl:template>

The data is here:
<URL:http://www.weft.co.uk/withmapsdemo/primitive?category=9>

So what's the problem?

Well, if you run it form the command line, e.g.

-[simon]-> xsltproc pres-news-map.xsl primitive.xml

It works OK and you get this:
<URL:http://www.weft.co.uk/withmapsdemo/demo.html>
(yes, there's a minor JavaScript error, but I'm not too bothered about
that just now); the critical bit is formatted

point = new GPoint( -3.94888888888889, 54.9488888888889);

var marker1 =
createMarker(point, "/pres/story/article_64.html",
"Gareth's off to a Land Down Under", "Friday, 13 January, 2006");

map.addOverlay(marker1);

But if you run it server-side, as I usually do, you get back in the DOM
tree not one big CDATA node, but a series of Text nodes, even if you do

doc.getDocumentElement().normalize();

(which I do). Because it's Text and not CDATA, XML syntax characters in
it get entified on printing, and you get:

point = new GPoint(
-3.94888888888889
,
54.9488888888889
);
var
marker1
=
createMarker(point,
&quot;/pres/story/article_64.html&quot;
,
&quot;Gareth's off to a Land Down Under&quot;
,
&quot;Friday, 13 January, 2006&quot;
);

map.addOverlay(
marker1
);

which the JavaScript engines simply don't recognise as JavaScript at all.

Finally, if you run the transform the XML client side (which you will do
if you go to <http://www.weft.co.uk/withmapsdemo/newsmap> with a browser
which sends either text/xml or application/xml in its Accepts header),
you get (or at least I do, with Firefox) absolutely nothing at all.

Any ideas about what I've got wrong, and how I can fix this?

--
si***@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

;; this is not a .sig
Mar 11 '06 #1
Share this Question
Share on Google+
10 Replies


P: n/a
Simon Brooke wrote:
Here's my problem:

<xsl:template match="/category">
...
<script
type="text/javascript">
&lt;![CDATA[


A CDATA section is not for JavaScript, but for the XSLT transformer to
indicate that the following block should be ignored.

That knowing, the syntax should be as follows:

<script type="text/javascript">
// <![CDATA[
...
// ]]>
</script>
JW
Mar 11 '06 #2

P: n/a
Janwillem Borleffs wrote:
A CDATA section is not for JavaScript, but for the XSLT transformer to
indicate that the following block should be ignored.


Quick reminder: CDATA sections are only (and I stress ONLY!) an
alternative to escaping single characters, for the convenience of humans
doing cut-and-paste of textual data into an XML document. XML tools
generally do not consider the difference between
<a><![CDATA[<b>]]></a>
and
<a>&lt;b></a>
to be meaningful. In particular, XSLT treats the two as identical.
--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry
Mar 11 '06 #3

P: n/a
Slight correction: XSLT treats the as identical on input.

On output, you can use the cdata-section-elements directive of
xsl:output to identify elements whose text content should be wrapped in
CDATA sections. Note the word "should" -- depending on how the output of
the stylesheet is handled, that distinction may not be preserved. Also
note that this is an all-instances-of-this-kind-ofelement directive; you
can't do it on a case by case basis.

Also note that since it does this for all text children of those
elements, it does *not* address the case of wanting some of the text
outside the CDATA.
Mar 11 '06 #4

P: n/a
Simon Brooke wrote:
Here's my problem:
Um, are you trying to run XSLT+javascript in a single step?

I think you need to chain them, with the XSLT coming first.
If it all needs to be done on the fly, you've got a big
performance hit anyway ...

You can certainly run XSLT in a filter - e.g. mod_transform.
Not sure about javascript: that's customarily delegated to
browsers (or avoided altogether:-) in my world.
But if you run it server-side, as I usually do,


Can your javascript processor be chained?

--
Nick Kew
Mar 11 '06 #5

P: n/a
in message <qv************@asgard.webthing.com>, Nick Kew
('n***@asgard.webthing.com') wrote:
Simon Brooke wrote:
Here's my problem:
Um, are you trying to run XSLT+javascript in a single step?

I think you need to chain them, with the XSLT coming first.
If it all needs to be done on the fly, you've got a big
performance hit anyway ...


Yup. This all gets cached, so that repeated requests with the same query
part will get the result from the cache. It's only if the cache is stale
that I'll regenerate.
You can certainly run XSLT in a filter - e.g. mod_transform.
Yup, I already have my own component to do that:

http://www.weft.co.uk/library/jacqua...achedPage.html
Not sure about javascript: that's customarily delegated to
browsers (or avoided altogether:-) in my world.
> But if you run it server-side, as I usually do,


Can your javascript processor be chained?


The JavaScript gets processed client-side. I'm fairly sure, for the
Google Maps interface, that it has to - different JavaScript is chained
by Google for different clients. Obviously, I don't control what happens
if I hand off the XSL processing to the client, which is why I usually
do it server side.

--
si***@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
;;Drivers in the UK kill more people every single year than
;; Al Qaeda have ever killed in any single year.
Mar 11 '06 #6

P: n/a
in message <75******************************@comcast.com>, Joe Kesselman
('k*************@comcast.net') wrote:
Janwillem Borleffs wrote:
A CDATA section is not for JavaScript, but for the XSLT transformer
to indicate that the following block should be ignored.


Quick reminder: CDATA sections are only (and I stress ONLY!) an
alternative to escaping single characters, for the convenience of
humans doing cut-and-paste of textual data into an XML document. XML
tools generally do not consider the difference between
<a><![CDATA[<b>]]></a>
and
<a>&lt;b></a>
to be meaningful. In particular, XSLT treats the two as identical.


We may be at cross purposes here, but it appears to me that this is
incorrect. Example: apply this stylesheet

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0">
<xsl:template match="foo">
<![CDATA[
<xsl:apply-templates select="bar"/>
]]>
</xsl:template>

<xsl:template match="bar">
bar <xsl:value-of select="position()"/> matched!
<xsl:apply-templates/>
</xsl:template>
</xsl:stylesheet>

to this XML:

<foo>
<bar>
Hello there!
</bar>
</foo>

yields:

<?xml version="1.0" encoding="UTF-8"?>

&lt;xsl:apply-templates select="bar"/&gt;

in xsltproc, Xalan, and Saxon. However, replace '<![CDATA[' with
'&lt;![CDATA[' and ']]>' with ']]&gt;' and you get:

<?xml version="1.0" encoding="UTF-8"?>

&lt;![CDATA[

bar 1 matched!

Hello there!

]]&gt;

with xsltproc, Xalan, and Saxon. So unless all three are wrong,
XSL /does/ /not/ process the contents of a CDATA section, but /does/
process a section which will be rendered as a CDATA section when
serialised.

--
si***@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

;; I can't work yanks out......
;; Why do they frown upon sex yet relish violence?
;; Deep Fried Lettuce
Mar 11 '06 #7

P: n/a
in message <Ge********************@comcast.com>, Joe Kesselman
('k*************@comcast.net') wrote:
Slight correction: XSLT treats the as identical on input.

On output, you can use the cdata-section-elements directive of
xsl:output to identify elements whose text content should be wrapped in
CDATA sections.


Ah! Kwa-tcha! Thank you. 'cdata-section-elements="script"' seems to be a
big step towards what I need; you need to use 'method="xml"' as well.
Fixing the serialiser seems to be the rest. I'm still finding that even
after using cdata-section-elements="script" and using
Document.getDocumentElement().normalize() the DomImplementation is still
passing the contents to me as a series of fragmentary text nodes rather
than as a single CDATA node, which means I escape the contents... Damn.
Still, I can make it work with this. Thanks.

--
si***@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/

;; I'd rather live in sybar-space

Mar 11 '06 #8

P: n/a
In article <nj************@gododdin.internal.jasmine.org.uk >,
Simon Brooke <si***@jasmine.org.uk> wrote:
XML
tools generally do not consider the difference between
<a><![CDATA[<b>]]></a>
and
<a>&lt;b></a>
to be meaningful. In particular, XSLT treats the two as identical.
We may be at cross purposes here,
You are :-)
but it appears to me that this is
incorrect. Example: apply this stylesheet
[...]
<![CDATA[
<xsl:apply-templates select="bar"/>
]]>
[...]
However, replace '<![CDATA[' with
'&lt;![CDATA[' and ']]>' with ']]&gt;'


That wasn't the transformation Joe specified. He was completely
removing the <![CDATA[ and ]]> and escaping the special characters
inside. The escaped equivalent is:

&lt;xsl:apply-templates select="bar"/&gt;

To reiterate: as far as XML is concerned, CDATA sections are an
escaping mechamism that is equivalent to, but often more readable
than, character or entity references. Non-XML tools may treat them
differently, but this is dangerous since almost any XML processing
may change CDATA sections to other escaping.

-- Richard

Mar 11 '06 #9

P: n/a
Simon Brooke wrote:
Here's my problem:

<xsl:template match="/category">
...
<script
type="text/javascript">
&lt;![CDATA[


See the FAQ at http://xml.silmaril.ie/authors/cdata/

///Peter
Mar 11 '06 #10

P: n/a
in message <fq************@gododdin.internal.jasmine.org.uk >, Simon
Brooke ('s****@jasmine.org.uk') wrote:
in message <Ge********************@comcast.com>, Joe Kesselman
('k*************@comcast.net') wrote:
Slight correction: XSLT treats the as identical on input.

On output, you can use the cdata-section-elements directive of
xsl:output to identify elements whose text content should be wrapped
in CDATA sections.


Ah! Kwa-tcha! Thank you. 'cdata-section-elements="script"' seems to be
a big step towards what I need; you need to use 'method="xml"' as well.
Fixing the serialiser seems to be the rest. I'm still finding that even
after using cdata-section-elements="script" and using
Document.getDocumentElement().normalize() the DomImplementation is
still passing the contents to me as a series of fragmentary text nodes
rather than as a single CDATA node, which means I escape the
contents... Damn. Still, I can make it work with this. Thanks.


On further investigation, all those who said that CDATA had nothing to do
with the case were, of course, perfectly correct. The fundamental
problem is bugs in my serialiser. Which I now need to fix. Bother.

--
si***@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
; ... of course nothing said here will be taken notice of by
; the W3C. The official place to be ignored is on www-style or
; www-html. -- George Lund

Mar 13 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.