Given the need to create this horrible format, one way around it is to use
character maps (or even d-o-e) to create the start and end comment
delimiters. That way, the serializer doesn't know you're in the middle of a
comment, so it will output elements as if they were regular elements.

Another way is to output the comment as an element <comment>...</comment>
and then postprocess with a text editor:

s|<comment>|<!--|
s|</comment>|-->|

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: Jon Gorman [mailto:jonathan.gorman@xxxxxxxxx] 
> Sent: 02 May 2006 18:39
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: RE:  Producing Excel 2000 htm files: how do 
> I manage the hidden stuff
> 
> On 5/2/06, cknell@xxxxxxxxxx <cknell@xxxxxxxxxx> wrote:
> > The direct answer is, "Because I didn't think of it." 
> Having now tried it, I can tell you that it strips away all 
> the XML markup from the document, leaving only the element contents.
> 
> It creates an comment, just like xsl:element.  The content of 
> the comment are determined by what the xsl:comment element contains. 
> Remember that a comment doesn't contain markup (since it is 
> after all, just text).  So when you have a element somewhere 
> in the template, it returns just the text value.  (Just as if 
> you evaluated an element as a string elsewhere in XSLT).
> 
> If you want to complate the sin of inserting functionality in 
> a non-functional part of the xml document, you'll need to 
> tell it what text you want to output (ie the "looks like 
> markup" but is not).
> 
> So one possible way of doing this would be something like:
> 
>  <xsl:template match="*" mode="insideComment">
>      <xsl:text>&lt;</xsl:text><xsl:value-of select="name(.)"
> /><xsl:text>&gt;</xsl:text>
> <xsl:apply-templates />
> <xsl:text>&lt;/</xsl:text><xsl:value-of select="name(.)"
> /><xsl:text>&gt;</xsl:text>
>    </xsl:template>
> 
> 
> 
> Of course, I wonder more:
> 1) Why not just do it in the Excel xml format if your target 
> is Excel 2000.  I thought that was more well supported and 
> documented for the 2000 version?
> 
> 2) Why not use some other XML techniques (SAX or DOM) or 
> libraries in conjunction with XSLT to produce an Excel 
> binary?  This is an approach I find myself taking, but mostly 
> because of a mixed user base who might be still using 
> versions of Excel earlier than 2000.
> 
> Jon Gorman