RE: Scripting media types registration progress

I just received this message to HCG, which bears careful study. Bjoern is proposing text/* and application/* types for JavaScript/ECMAScript with requirements related to encodings.

Addison

Addison P. Phillips
Director, Globalization Architecture
http://www.webMethods.com

Chair, W3C Internationalization Core Working Group
http://www.w3.org/International

Internationalization is an architecture. 
It is not a feature.

> -----Original Message-----
> From: w3c-html-cg-request@w3.org 
> [mailto:w3c-html-cg-request@w3.org]On Behalf Of Bjoern Hoehrmann
> Sent: 2005年2月3日 17:00
> To: w3c-html-cg@w3.org
> Subject: FYI: Scripting media types registration progress
> 
> 
> 
> Dear Hypertext Coordination Group,
> 
>   I've produced a new Internet-Draft that registers media types for the
> JavaScript and ECMAScript programming languages in response to popular
> request. The draft is not yet final and not yet submitted but as you are
> going to meet soonish, I considered an advance notice to be useful. I
> expect that the Internet-Draft be published early next week and that the
> IESG announces a Last Call for the document along with the publication.
> 
> If all goes well it should be published as Informational RFC in April
> 2005 or ealier. The HCG (or the individual groups) should review the
> draft once it is published to ensure it meets the needs of the Working
> Groups. A statement of support for the document on the ietf-types list
> will help the document to advance. I'll inform the HCG once the draft
> gets published. The remainder of this note discusses the draft in more
> detail and how it might impact existing and future work of the groups
> in the Hypertext CG.
> 
> A snapshot of my working copy is available from:
> 
>   
> http://lists.w3.org/Archives/Member/w3c-archive/2005Feb/att-0054/d
> raft-hoehrmann-script-types-01.txt
> 
> The document registers the (previously unregistered & undefined) types
> 
>   * text/javascript
>   * text/ecmascript
>   * application/javascript
>   * application/ecmascript
> 
> defines how implementations determine the character encoding of scripts
> and explains in 700+ words that security considerations are out of scope
> of the document. It notes that a future version is expected to deprecate
> the type text/ecmascript and one of the javascript types (which would
> likely be text/javascript but the draft avoids saying that). The text/*
> variants are not really suitable for executable content and have i18n
> issues (as discussed in RFC3023).
> 
> The preference of the application/* types addresses the only substantial
> concern raised against the previous draft (which preferred the text/*
> types simply because that's what most authors are familiar with and as
> the i18n issues are ignored in practise anyway). ECMA TC39 in particular
> requested that application/ecmascript be the only official type, but as
> the intent of the draft is to register legacy types, I have not removed
> text/ecmascript from the draft.
> 
> ECMA TC39 further requested an application/ecmascript4 type for ECMA262
> Edition 4 (basis for ActionScript 2.0, JScript .NET, JavaScript 2.0)
> which is still not final yet (the request came in 2001) so the document
> does not register such a type.
> 
> It further does not address ECMA 357 (ECMAScript for XML, E4X); Mozilla
> have implemented an, as far as I understand, ad-hoc, experimental
> parameter "e4x=1" in their E4X implementation to indicate use of E4X.
> The document does not have such a parameter but reserves a "version"
> parameter to allow further extension of the media type application/
> ecmascript.
> 
> The character encoding detection requirements are marked as SHOULD for
> all types but application/ecmascript for which they MUST be implemented
> as written. The encoding detection algorithm is similar to that for
> XML, the charset is authoriative, if there is no charset, the first
> octets are inspected for a unicode signature to detect UTF-8/16/32 and
> if that fails it is UTF-8.
> 
> This document impacts W3C Technical Reports that require support for
> Ecmascript, for example, SVG 1.x, VoiceXML 2.x, and CCXML 1.0 and could
> impact all Technical Reports that allow for scripting as far as that
> involves specifying the media type of the script or external scripts.
> 
> New Technical Reports that require support for text/ecmascript (such as
> SVG 1.2) should also require support for application/ecmascript; if
> there is a default value of text/ecmascript the default value should
> change to application/ecmascript as far as that is possible to do while
> considering legacy implementations and/or content.
> 
> Technical Reports that include requirements to detect the character
> encoding of external scripts should be reviewed and possibly updated in
> light of the draft. For example, VoiceXML 2.0 allows for
> 
>   <x:script src = 'foo.es' charset = '...' />
> 
> and considers the default value of the charset attribute UTF-8. It is
> not clear whether this means the attribute value is authoriative; it
> cannot be authoriative as resource meta data is authoriative,
> 
>   http://www.w3.org/2001/tag/doc/mime-respect.html
> 
> so the Working Group might consider publication of normative corrections
> to that effect. (It is further not clear if the script starts with a
> byte order mark whether the sequence is ignored or considered source
> text...) I believe the same applies to CCXML.
> 
> For document languages that allow a to specify the media type of scripts
> (typically via <script type="text/ecmascript">) there might be further
> impact depending on the value space of the attribute. XHTML and SVG have
> such a construct and I've filed comments that this is clarified in the
> relevant document. The issue is whether e.g.
> 
>   <script type="application/ecmascript;version=4">
>   <script src="..." type="application/ecmascript;charset=iso-8859-1" />
> 
> is allowed and how this is to be processed. If this is not allowed there
> is an extensibility problem, you cannot use other scripting languages in
> the document and might have trouble to do so using external scripts. If
> it is allowed, it is not clear how the character encoding of the script
> in the second example is determined, or whether the user agent would at
> all attempt to retrieve the resource if iso-8859-1 is not supported.
> 
> Note that the draft requires that a/ecmascript resources labeled with a
> version parameter are to be ignored by user agents (otherwise breaking
> changes could not be introduced in a backwards-compatible manner). This
> should be clear from new technical reports that require application/
> ecmascript support and allow using parameters in such attributes (and
> possibly also for external scripts).
> 
> I am going to produce a (ideally re-usable) test suite for at least the
> application/ecmascript media type as far as requirements imposed by the
> media type registration are concerned, i.e., for character encoding de-
> tection, encoding error handling, and support for the version parameter;
> 
> I expect to provide a script that generates test files according to a
> template such that test for many host languages can easily be produced;
> if working groups have guidelines for new tests for their test suites I
> would appreciate a pointer to these guidelines to consider them in this
> process to allow for seamless integration of such new tests.
> 
> Thanks,
> -- 
> 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 Friday, 4 February 2005 01:50:36 UTC