[www-svg] <none>

4414182.8361.16.camel@sphinx> <127307864937.20020618173958@w3.org>
Subject: Re: The 'image/svg+xml' Media Type
Date: Tue, 18 Jun 2002 15:50:33 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

"Chris Lilley" <chris@w3.org>
> On Tuesday, June 18, 2002, 5:29:41 PM, Braden wrote:
>
>
> BM> On Tue, 2002-06-18 at 08:40, Jim Ley wrote:
>
> BM> [snip]
>
> >> 5.1 Notes on text/ecmascript
> >>
> >>    By the best of the author's knowledge, this Media Type has been
> >>    introduced by the SVG [SVG10] specifications.  It is beeing used
> >>    there and defined as the default value for the
'contentScriptType'
> >>    attribute of the 'svg' element.
> >>
> >> I'd again suggest that it was never the place of an SVG working
group to
> >> invent a mime-type for ECMAScript.
> Other options being
>
> a) pick "javascript" instead (netscape copyright name, poorly
documented)

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

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

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

I certainly think leaving developers and implementors to develop a
standard and to encourage the debate and registration of a mime-type for
ECMAScript would've been appropriate.

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

because according to RFC 2046 text/ is for

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

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

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

Jim.

Received on Tuesday, 18 June 2002 11:53:19 UTC