Thanks. I was indeed using xslt wrong. I had always generated html output in the past and this was the first time I simply needed to perform simple transforms (xml-to-xml) and didn't even know the basics with that. Now I do, it works as advertised simply using element and attribute statements. Thanks!

DOE solved my problem.
Thanks

If you think DOE (disable output escaping - I presume) has solved your problem them you've probably tackled the problem the wrong way. DOE is severely deprecated and not guaranteed to work at all. In the case you outlined above surely <xsl:text>& # 1 0 ;</xsl:text> (without the spaces) would work? If not then there's something odd in your process that's causing a double-escaping of the output.

--

Joe (Microsoft MVP - XML)

Thanks for the heads up.

I've tried 4 different ways (note: all without spaces) with <Data> results following:

1)
<xsl:text>& # 1 0 ;</xsl:text>
<Data ss:Type="String">GROUP1
GROUP2</Data>

2)
<xsl:text>& a m p ; # 1 0 ;</xsl:text>
<Data ss:Type="String">GROUP1&amp;#10;GROUP2</Data>

3)
<xsl:text disable-output-escaping="yes">& # 1 0 ;</xsl:text>
<Data ss:Type="String">GROUP1
GROUP2</Data>

4)
<xsl:text disable-output-escaping="yes">& a m p ; # 1 0;</xsl:text>
<Data ss:Type="String">GROUP1#10;GROUP2</Data>

1 & 3 are resolving to a invisible linefeed in the xml.
2 resolves to & a m p ; # 1 0 ; which is close.
4 is the only one that gives me the visible & # 1 0 ;

I'll need to do more checking to know why I need DOE.

Thanks again.

I see, well in theory there's no difference between a "real" linefeed and & # 1 0 ; - so using (1) should be fine. I've tested what you described agree with you, when you ask for & # 1 0 ; it outputs a linefeed and a carriage return (& # 1 3 ;). I'll try to find out why. Which transformer are you using?

--

Joe (Microsoft MVP - XML)

I'm using C# .NET 2.0. Maybe that's the reason.


public class Transformer
{
    public static void TransformXml(string xmlSourceFileName, string xmlResultFileName, string xsltFileName)
    {
        XPathDocument doc = new XPathDocument(xmlSourceFileName);
        XPathNavigator nav = ((IXPathNavigable)doc).CreateNavigator();
        XslCompiledTransform compiledTransform = new XslCompiledTransform(true); // true for debugging support
        compiledTransform.Load(xsltFileName);

        FileStream fs = new FileStream(xmlResultFileName, FileMode.Create);
        compiledTransform.Transform(nav, null, fs);
    }
}

Yes, but Excel is handling the character incorrectly, irrespective of how the XML is produced. It should treat & # 1 0 ; identically to a bona fide line feed. I've posted a support call to the XML development team in Redmond.

--

Joe (Microsoft MVP - XML)