Scripting Media Types

[ned.freed at mrochek.com]

> * Bruce Lilly wrote:
> >First, the proposed text subtypes are inappropriate; text subtypes
> >are reserved for human-readable text content, with or without
> >markup; see RFC 2046 section 4.  They are not to be used for
> >arbitrary content which happens to be textual, such as programming
> >and scripting languages; they are reserved for natural language.

> That's probably true, but the alternative would be to continue using the
> unregistered types for several years as the application/* types are much
> less well-supported. For example, all SVG implementations I am aware of
> that support relevant scripting,support text/ecmascript (as the relevant
> specifications suggest) while none support application/ecmascript. There
> are about a million hits for type="text/*" but only a few hundred hits
> for type="application/*" using Google (where * are the relevant subtypes
> from the draft).

> There are also several other registered media types that are not meant
> to be used for natural language, for example, text/css, text/uri-list,
> text/vnd.wap.wmlscript, text/sgml, and text/xml do not fit into this
> category (either by their very nature as for text/css or by their use
> in common practise as for text/xml, though I admit that one can greatly
> argue about each type), I thus do not think that it is generally not
> possible to register such types under the text top-level type.

First, the criteria is "meaningful to present directly to a human", not
"is composed of natural language text".

Second, some of these registrations are widely thought to be mistakes -
they never should have been registered under text. As such, they don't
justify additional, similar registrations.

> If you
> consider the content to be "source code" rather than "executable code"
> it is for many people in fact difficult to find much difference between
> types such as text/html and text/ecmascript.

> There are even people who would prefer to just stick with the most
> commonly used types (which would be text/javascript, etc) simply because
> that's what's implemented, what authors use, what you can find in speci-
> fications, documentation, books, etc.pp.

> The types are currently unregistered and pretty much undefined, the
> draft defines underdefined aspects, provides security considerations
> for the types, and would register those types if the draft is approved.
> I think this is more valuable than to keep using the types as-is. In
> particular, I think it would actually help the IANA registry to gain
> relevance if it is less out of touch with reality. On several occasions
> I've contacted organizations to encourage them to register the types
> they use and/or define and I've generally been told that people don't
> bother as the registry is of too little relevance to them. The more it
> reflects reality, the more I would expect people to care, which would
> encourage more review of new types which would consequently encourage
> a more well-defined infrastructure.

The fact that these subtypes of text are in widespread use leads me to suggest
an alternate approach: Why not register them, but mark them as obsolete with a
pointer to the type that should be used instead? The registration will then
serve two purposes: To make it clear what the types contain when they are used
and to also make it clear they should no longer be used. 

> Thus, without arguing about whether text/* is the best place for these
> types (and the draft admits that it is probably not),

Hinting isn't sufficient IMO. We're trying to provide usage guidance here,
so the problematic nature of calling this sort of material text should
discussed.

				Ned