Re: [VoiceXML 2.1] New scripting media types

* Kazuyuki Ashimura wrote:
>During the development of VoiceXML, the Voice Browser Working Group
>has encountered an issue that it thinks should be submitted to the
>TAG. The problem is about how newly registered media types should be
>integrated back into existing specification.
>
>The case at hand is the new media type 'application/ecmascript' [1]
>not normatively defined yet, but which is recently became a new
>Informational RFC (RFC4329). This document obsoletes the old types
>'text/ecmascript' and 'text/javascript' and states that the only
>appropriate media type for external scripts is
>'application/ecmascript'.

The IESG approved draft-hoehrmann-script-types-03.txt about a year ago,
which registered the four types normatively described in that document;
none of the types in the document is really new, application/ecmascript
for example occurs in ISO/IEC 19777 and ISO/IEC 19775. All the types in
the document have not been registered before, and all four of them are
"out" and normatively defined since the IESG approved the I-D mentioned
above (as I told the Hypertext Coordination Group at the time).

Also note that application/javascript is an appropriate type for Java-
Script resources, which includes most if not all ECMAScript resources.

>The question is: once this media type comes out, how will it affect
>existing specifications that support external ECMAScript scripts and
>that either mention obsoleted unregistered types, or don't mention
>types at all.

Keeping specifications up to date encourages standards-compliant and
interoperable adoption and use of the specified technology; if that
is desired, the specification should certainly be updated one way or
another to provide accurate and up to date information.

>Is it recommended that the specifications be amended through errata,
>and implementations be changed accordingly?

Implementers that directly or indirectly claim support for one of the
types defined in RFC 4329 should certainly review and if needed update
their implementations such that they conform to the requirements set
forth for that type. Whether they should add support for additional
types as defined in RFC 4329 might depend on implementation-specific
considerations.

As for specifications, a good example is the SVG 1.1 Recommendation.
It requires support for the then-unregistered type text/ecmascript.
Some SVG 1.1 implementers refused to add support for that type as it
was not a registered type. As a result content that made use of the
type worked in some implementations and not in others, clearly not
a desirable situation. Further, SVG 1.1 did not define many aspects
of the type, such as character encoding recognition, and so the SVG
implementations failed to interoperate in many cases.

As another consequence of how most of the types in RFC 4329 got in-
troduced, there is a considerable amount of legacy content that ex-
isting implementations wish to continue to support. Therefore, some
of the interoperability problems cannot easily be addressed. As ex-
plained in RFC 4329, application/ecmascript content was virtually
inexistant at the time of approval, and so legacy content does not
hinder adoption of more robust and interoperable processing rules.
So application/ecmascript is easiest to implement and most reliable
to use.

So for ECMAScript scripts, application/ecmascript is the most web
standards compliant type, it gurantees a higher level of interopera-
bility among compliant implementations, and has fewer security risks;
authors will consequently want to use this type instead of some other
type. So the question is how related specifications enable them to do
that. Appropriate conformance requirements and/or non-normative
discussion in those specifications is a good way to achieve that.

For VoiceXML 2.1 this means it should require support for the type in
much the same way as other work in progress specifications like those
by the CDF and SVG Working Groups already do, and so I have requested.
Failing that the Working Group would have to explain why use of
application/ecmascript is unimportant to authors or how some other
course of action is so much better that making it less likely that
VoiceXML 2.1 implementations implement application/ecmascript correctly
is acceptable.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 11 July 2006 19:25:38 UTC