[www-svg] <none>

>>>>> "JL" == Jim Ley <jim@jibbering.com> writes:

>> I'd again suggest that it was never the place of an SVG working
>> group to invent a mime-type for ECMAScript.  

CL> Other options being:

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

    Did they require an ecma script engine?

    SVG Dynamic requires an implementation provide an ECMAScript
interpreter.  This would be completely pointless if we didn't provide
content providers with a standard way to invoke that interpreter.

    If all the SVG developers are all using text/ecmascript but it
isn't in the SVG standard this changes things how? The only way I can
see is that you are more likely to have confused users (what do I call
this?) and incompatible implementations.  Both great things for the
community.

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

    Thus, we would all still be waiting for SVG to make Rec (in spite
of several robust implementations) for some other group of people to
decide what they want to call ECMAScript content (hence we wouldn't
even have started to draft a mime-type registration for SVG) - Which
is why we are having this discussion.  Why didn't you raise this
objection when SVG was undergoing Public Review?

    I'm not saying it's great to go running off and defining mime
types willy nilly (which BTW W3C/SVG doesn't have the power to do, it
can simply say that if you want to invoke the ecmascript interpreter
in a conformant SVG implementation use 'text/ecmascript').

     Also it wouldn't surprise me if at the time 'text/ecmascript' was
fairly certain to be chosen, perhaps things have changed since then,
or we may be hearing a slanted view on things and it may still be the
most likely mime type. 

     I don't really know...

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

    I don't really want to get into this discussion but I don't see a
lot of parallels between ecmascript script and things like Word
Documents and zip files, etc.  I agree text is a stretch also but it
is 'text' all be it with a lot of implicit semantics.

Received on Tuesday, 18 June 2002 13:38:35 UTC