W3C home > Mailing lists > Public > www-svg@w3.org > January 2005

Re: SVG12: Script Encoding

From: Jim Ley <jim@jibbering.com>
Date: Sun, 16 Jan 2005 21:29:05 -0000
To: www-svg@w3.org
Message-ID: <csemc1$k3r$1@sea.gmane.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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:29 GMT