> The problem is the use of <xsl:template match="script"> and how XSLT
> processors treat it; the output node tree will be converted from its
> native form to whatever output you specify, and if that's XHTML 1.0

a) They will only do that (unless something strange is happening) if
   if you have specified script as a cdata-section-element in your
   xsl:stylesheet attributes.

b) they won't do that at all and they will generate exactly what you
   said you wanted if they support disable-output-escaping and you use the
   construct that I showed
> <xsl:text disable-output-escaping="yes"><![CDATA[
> //<![CDATA[
>   ..... stuff here ...
> //]]>]]&gt;
> </xsl:text>

If you do this you are not generating a script element in the output
tree, just some text that looks like a script element and so the
system will not mess with it at all, did you try this?

> No, but XSLT processors still throw it in if needed or not.
see above (or below)

David




<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
 <xsl:text disable-output-escaping="yes"><![CDATA[
 <script>
 //<![CDATA[
   ..... stuff here  with < and & and && and stuff
 //]]>]]&gt;
 &lt;/script>
 </xsl:text>
</xsl:template>

</xsl:stylesheet>


running the above (on itself, just as an example)

$ saxon doe.xsl doe.xsl
<?xml version="1.0" encoding="utf-8"?>
 <script>
 //<![CDATA[
   ..... stuff here  with < and & and && and stuff
 //]]>
 </script>
 

which is a script element with CDATA and javascript comment markup as
you wanted, produced by an XSLT1 processor.

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________