This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: •


[Greg Martel]

Anybody have helpful advice on why XML-Spy/xalan won't let me
redefine a numeric entity in  a stylesheet but will let me redefine
other entities.
--------------
(Redefining the entity using disable-output-escaping in the XSL
stylesheet DOES control the output. I got this technique out of Bob
Ducharme's "XSLT Quickly." Only I am unable for some reason to
redefine a NUMERIC entity in the XSL transform which was the point of
my question.

And the setup works for a dynamic browser transform just fine; but it
also needs to work for html which is going to be posted after the
transform.)



[Tom P]

You've gotten a lot of good information about your questions, but it may
have been a little too fragmented.  Let my try to pull it together.

1) Your things - • - are called "character references", not
"entities".  You cannot define them, you just use them.

2) There are three separate issues
        a) How to handle the xml side
        b) How to handle the xslt processing.
        c) What you want the browser to display, and how to cause that to
happen.

        Also, there may be an issue of what will display in your editor (or
Spy) vs. what the character really is vs what the browser will show.

On the xml side, just use the character reference as is ("•").  This
unambiguously, independent of encoding, specifies which exact character you
mean.

On the browser side, most browser won't display utf-8 unless told to do so
(usually by a Preference ssetting), and some older ones just can't do so at
all.  Most browsers are set for Latin-1, at least in the US.  It's probably
safest to use iso-8859-1, not because it's completely universal but because
most xslt processors can produce output in that encoding.

Browsers understand character references.  Your job is to hand the browser
characters in an encoding it can handle, or as character references if it
can't handle the encoding.

On the xslt side, specify an output encoding equal to the browser setting if
 possible.  The xslt processor will output character references for any
character that it can't represent in the encoding, and the browser will be
happy.  Don't try to fake the character references by tricks using
disable-output-escaping.  As you have seen, that ranges from hard to
impossible.

If you can't count on the browser's encoding abilities, then you could force
all high order characters to be output as character references by using
us-ascii encoding, but not all xslt processors support us-ascii (they are
only required to support utf-8 and utf-16, but almost all will do iso-8859-1
as well).

Finally, you could have the correct character correctly encoded in the
output file, but still see a strange display in your editor.  For example,
if you used utf-8 encoding but your editor did not understand utf-8, then
high order characters would display strangely.  This is common on Windows
systems, depending on the version of Windows and on the application.

So even if a character looks odd in your editor, it might still be correct
and might still display right in a browser.

I haven't covered how to get a browser to use a particular encoding without
having to change preferences, because I don't know.  Anyone know if there is
an accepted way?  HTTP headers would be one, but I'm thinking of something
embedded in the document itself.

Hope this clears things up.

Cheers,

Tom P


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]