Subject: Re: [xsl] • From: "Thomas B. Passin" <tpassin@xxxxxxxxxxxx> Date: Mon, 10 Jun 2002 11:09:15 -0400 |
[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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] •, David Carlisle | Thread | Re: [xsl] •, J.Pietschmann |
RE: [xsl] calling java functions fr, Andrew Welch | Date | [xsl] multi-levels counter, Allen Chu |
Month |