- From: Chris Lilley <chris@w3.org>
- Date: Tue, 18 Jun 2002 18:49:24 +0200
- 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