Re: Using Entity References in XSL Templates

Subject: Re: Using Entity References in XSL Templates
From: David Carlisle <davidc@xxxxxxxxx>
Date: Fri, 21 Jan 2000 18:12:54 GMT
> but not with MSXML 
MSXML does not support XSLT but rather different language.
I see that MS are promising a `preview' release next wednesday
of a parser supporting xpath and xslt.

> coming through not as a non-breaking space, but as a Â

No you are only looking at _half_ the character, on a terminal using the
wrong encoding. The default XML encoding is UTF-8 (and xt currently does
not support changing that) in UTF-8 position 160 is encoded as two
bytes. If you look at the file on a terminal using latin1 then you see
the two bytes as two random characters, but a utf-8 terminal or a
browser which understands utf-8 (which is most of the current versions
of the main browsers) should do the right thing.

This must be the most F of FAQ's on this list though:-)

> Following your advice, I defined nbsp as follows:
>     <!DOCTYPE xsl:stylesheet [
>         <!ENTITY nbsp "<xsl:text
> disable-output-escaping='yes'>&amp;nbsp;</xsl:text>">
>     ]>
> This worked fine.

but it will stop working as soon as you use XSL in an embedded system
where the XML tree output from XSL is passed straight into another
application without being re-parsed.

If you output &#160; you are outputting the single unicode character 160
(even if it is two bytes in utf-8)

If you output &amp;nbsp;
then you are outputting the six characters
`ampersand' n b s p ;

_if_ your XSL engine decides to honour the disable-output-escaping (it
does not have to) you will get the characters &nbsp; in your output
but that will only be the no break space character if you re-parse your
entire document. If you pass it straight into the dom of a browser,
you'll see what you asked for, the 6 characters &nbsp;.

this seems a high price to pay, just to get the character appearing
as something you can read in a non-unicode aware terminal or editor.


 XSL-List info and archive:

Current Thread