RE: [xsl] MSXML / NBSP problem and resolution

Subject: RE: [xsl] MSXML / NBSP problem and resolution
From: "Ben Robb" <Ben@xxxxxxxxxx>
Date: Fri, 8 Nov 2002 09:29:58 -0000
I'd agree that it's a problem with XML Spy - I've used MSXML 3 and 4 without any issues with &#160; - it even seems to cope with the trauma of going through VBScript on the way through.

In answer to someone's other question (way up in the thread) to avoid going through the whole trauma of strings being recast as Unicode, the solution is to output directly to the Response stream by using the "oXSLProcessor.Output = Response" method. That way it is never cast as a string (and is therefore very much more efficient too, due to VB(Script)'s terrible way of handling memory management for strings).



-----Original Message-----
From: Mike Brown [mailto:mike@xxxxxxxx] 
Sent: 08 November 2002 04:37
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] MSXML / NBSP problem and resolution

Greg Faron wrote:
>    Just to chime in, I've had issues with this using XML Spy 4.4 to 
> convert
> files (via MSXML 4).  First, any occurrence of &#160; in the XSL Stylesheet 
> gets replaced with just a space character during processing, so a 
> stylesheet line of
> <td>&#160;</td>
> creates the output
> <td> </td>

I am pretty certain that XML Spy actually creates <td> </td>. The encoded no-break space character is in between the tags. In this email I used byte 0xA0 because that's how you represent no-break space directly in iso-8859-1. Of course the two different kinds of spaces are indistinguishable visually.

If I were making an effort to stick to us-ascii in this email, there's no byte 
for no-break space, so I'd have to resort to using a character reference or 
entity reference.

> This poses an issue within XML Spy since the auto-indent editing 
> feature
> will truncate the latter to <td/>

IIRC, in some function somewhere in Windows, U+00A0 is considered to be whitespace. XML Spy's indenter probably relies on such a function where it shouldn't. So this is probably where the bug is in XML Spy.

>    BTW, it's also a shame that MSXML ignores the "indent" attribute of
> xsl:output, but that's something else altogether.

Huh? Given this as test.xsl:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
  <xsl:output method="html" indent="no" encoding="iso-8859-1"/>
  <xsl:template match="/">
            <td>hello world</td>
            <td>goodbye cruel world</td>

And invoking MSXML via msxsl.exe:

C:\dev>msxsl \temp\test.xsl \temp\test.xsl
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>test</title></head><body><h1>test</h1><table><tr><td>hello 
world</td><td>goodbye cruel world</td></tr></table></body></html>

...and after changing indent to "yes":

C:\dev>msxsl \temp\test.xsl \temp\test.xsl
<META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>test</title> </head> <body> <h1>test</h1> <table> <tr> <td>hello world</td> <td>goodbye cruel world</td> </tr> </table> </body> </html>

It looks like it is honoring the attribute to me. Perhaps you were expecting a greater degree of indenting?

   - Mike ____________________________________________________________________________
  mike j. brown                   |  xml/xslt:
  denver/boulder, colorado, usa   |  resume:

 XSL-List info and archive:

 XSL-List info and archive:

Current Thread