Re: The interpretation of script

Norman Walsh scripsit:

> In principle, there's no reasy why the browser couldn't equally
> execute application/xslt+xml or application/xproc+xml or
> application/normslanguage content.

I think this is more of a theoretical than a practical problem.  Despite
the code/data duality of XML (and Lisp), we typically know whether a given
piece of text is code or data.  The underpinnings of the xqib system know
that browsers treat application/xquery as inert data, but they make it
their job to give it an interpretation as a script.  If you don't want
your XQuery interpreted as a script, give it a media type of text/plain.

In general, the only reason media types like application/javascript exist
at all is to provide "liveness".  From a strictly MIME point of view,
they could just as well be text/plain.

> This problem bites doubly hard, because I believe a significant
> argument in favor of the script tag is for legacy compatibility. This
> implies that if I *did* want to make a browser that, for example,
> executed applciation/normslanguage content,

Suggested rewording: for "make a browser that executed" read "make a
browser execute", which means that the execution could be either native
or mediated through JavaScript.)

> I'd have to some how make sure that there was no legacy content with
> that type.

I think that's a safe assumption if you use a new media-type for every
such language.  True, some media types have pre-empted the registry,
but I doubt if even a single instance of "application/normslanguage"
exists out there, especially if you misspell "application".  :-)

> On the face of it, it would seem that some forward-looking adaptation
> would be valuable. I'd prefer a <foreign-content> element, with
> appropriate semantics over <script>, but I appreciate that this is not
> without problems. (For my part, if we think the life expectancy of
> HTML is effectively indefinite, adding a new element now even if I
> couldn't rely on it for 10 years would still be better.)

Please, no.  I do not want to see the list of elements with funky parsings
grow any longer.

> But even something as simple as a (NO)RUN attribute on script (which
> wouldn't cause any problems in legacy browsers) would at least provide
> a way to make my intention explicit.

The objection, I think, is the usual objection to rarely executed code
paths: they are more likely to have hidden bugs.  Though I admit this
one is particularly simple.

-- 
John Cowan    http://www.ccil.org/~cowan   <cowan@ccil.org>
    "Any legal document draws most of its meaning from context.  A telegram
    that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
    5-bit Baudot code plus appropriate headers) is as good a legal document
    as any, even sans digital signature." --me

Received on Monday, 17 January 2011 21:24:43 UTC