W3C home > Mailing lists > Public > www-svg@w3.org > June 2002

Re: [www-svg] <none>

From: Chris Lilley <chris@w3.org>
Date: Tue, 18 Jun 2002 18:49:24 +0200
Message-ID: <165312031531.20020618184924@w3.org>
To: www-svg@w3.org, "Jim Ley" <jim@jibbering.com>

On Tuesday, June 18, 2002, 5:53:18 PM, Jim wrote:

>> a) pick "javascript" instead (netscape copyright name, poorly
JL> documented)

JL> It's a trademark of Sun actually, I think there'd be a good argument for
JL> it being generic now in any case.

In fact, the ECMA committe asked to use the term 'javascript' and was
refused on trademark grounds. But its certaily possible that the Sun
license on the use of the term term Java in the name JavaScript was non-transferrable.

Either way, ECMAscript, now an international standard, is a better
choice all round.

>> b) pick "jscript" instead (microsoft copyright name, poorly documented)
>> c) leave it wide open and say scripters are on their own

JL> Well they already are on their own for the script type="..." it's only
JL> for the contentScriptType attribute, and as that logically needs to be
JL> the same as the contentScriptType I really don't think it would leave
JL> them any more at a loose end than any of the HTML recomendations - none
JL> of which felt the need to invent mime-types.

I think that bringing HTML recommendations into a discussion of
interoperability, tight specification, or good practice in MIME
registration is not going to do your argument a whole lot of good.

JL> I certainly think leaving developers and implementors to develop a
JL> standard

Developers and implementors already developed a standard. Its called ecmascript.

JL> and to encourage the debate and registration of a mime-type for
JL> ECMAScript would've been appropriate.

That part I can agree with, although a better time for such a
statement would have been during SVG 1.0 candidate recommendation.

>> BM> Furthermore, the type simply is wrong-headed.
JL> "application/ecmascript"
>> BM> is appropriate.
>> because .....

JL> because according to RFC 2046 text/ is for

(thanking you for appending a because clause)

JL>           text -- textual information.  [...] Other subtypes are to
JL>           used for enriched text in
JL>           forms where application software may enhance the
JL>           appearance of the text, but such software must not be
JL>           required in order to get the general idea of the
JL>           content.

You would be surprised how many people read scripts to get an idea of what they do.

JL> ECMAScript (especially when obfuscated) certainly does not meet those
JL> requirements.

JL> (I'd still like text/ecmascript registered and supported in Mozilla...)

While agreeing with your parenthetical statement, i do feel it is
somehow contradicted by the rest of your email.

 Chris                            mailto:chris@w3.org
Received on Tuesday, 18 June 2002 12:51:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:53 UTC