Re: SVG12: Script Encoding

* Jim Ley wrote:
>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.

To satisfy my request, many ways there are. The Working Group could add
a charset attribute to all such elements, it could propose a new version
of XLink with similar features and require it, it could require XInclude
support, and so on. I am even fully prepared to argue about the pros and
cons of approaching the problem by changing the svg:use element to be
usable with svg:script elements or to change the semantics of <script
xlink:href='foo.svg#script' ...> such that the functionality is at least
available for scripts in other SVG documents. It is even possible that
SVG 1.1 already requires such means through

  <script type="text/ecmascript;charset=..." ... />

but this is not yet clear to me as I've pointed out in

  http://www.w3.org/mid/41ec7862.266113906@smtp.bjoern.hoehrmann.de

If this is the case, this would accommodate your remarks that such
functionality should be available for relevant elements; well, except
that the type attribute is only available for svg:script and svg:style,
maybe someone should file an issue regarding this discrepancy...

>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.

I would expect that the feature provides a fallback character encoding
which would not ever conflict with other encoding information and thus
there would be no need for actual error processing rules other than the
usual suspects like that the encoding is not supported, the resource is
not actually encoded using that encoding, etc.

>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.

If the Working Group changes SVG 1.2 such that a version of ECMAScript
that is not subject to this problem is required, chances are that this
would satisfy my request aswell.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 16 January 2005 23:06:18 UTC