- From: Jim Ley <jim@jibbering.com>
- Date: Sun, 16 Jan 2005 21:29:05 -0000
- To: www-svg@w3.org
"Bjoern Hoehrmann" <derhoermi@gmx.net> wrote in message news:41eb7138.264280046@smtp.bjoern.hoehrmann.de... > Various document formats either provide or propose means to specify > the character encoding of external scripts if there is no reliable way > to determine the character encoding e.g. when loading the scripts from > the local disk if the file system does not support such meta data. > Among these formats are HTML 4.01 (<link rel=script charset=...>), > VoiceXML 2.0 (<script charset=...>), XHTML 2.0 (<script charset=...>) > and various derived formats. Please change SVG 1.2 to provide similar > means to ensure interoperable encoding detection for external scripts. Please do not change SVG 1.2 in this way, the encoding of documents external to SVG should be defined externally, and it should be consistent with other included content, ie if we don't have <image src="foo.svg" charset="..." /> then we shouldn't have it for scripts, there's nothing special about scripting languages that mean they cannot specify their character encoding in some way. Equally what happens when you're using a scripting language that does have a well defined character encoding resolution mechanism and the information in that is different, what are the error processing rules? For example my reading of the HTML 4.01 rules require that a UA with an XML based script language ignore the XML encoding methods and use the charset of a link to it instead, I do not think this is a good idea. If there are problems identifying ECMAScript (or other scripting languages) in such metadata-free systems as you discuss, fix it in ECMAScript as that will fix it for everyone. Jim.
Received on Sunday, 16 January 2005 21:29:44 UTC