I'd agree that it's a problem with XML Spy - I've used MSXML 3 and 4 without
any issues with   - 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).
HTH
Ben
-----Original Message-----
From: Mike Brown [mailto:mike(_at_)skew(_dot_)org]
Sent: 08 November 2002 04:37
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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   in the XSL Stylesheet
gets replaced with just a space character during processing, so a
stylesheet line of
<td> </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"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="html" indent="no" encoding="iso-8859-1"/>
<xsl:template match="/">
<html>
<head>
<title>test</title>
</head>
<body>
<h1>test</h1>
<table>
<tr>
<td>hello world</td>
<td>goodbye cruel world</td>
</tr>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
And invoking MSXML via msxsl.exe:
C:\dev>msxsl \temp\test.xsl \temp\test.xsl
<html><head>
<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
<html>
<head>
<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: http://skew.org/xml/
denver/boulder, colorado, usa | resume: http://skew.org/~mike/resume/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list