comments on initial draft

[allenwb]

Thanks for carrying this torch!

Note throughout that the proper capitalization is ECMAScript not EcmaScript

ECMA-262: author: org: European Computer Manufacturers Association title: "Standard ECMA-262" date: August 2017 target: http://www.ecma-international.org/publications/standards/Ecma-262-arch.htm

I'd reference this as:

ECMA-262: author: org: Ecma International title: "Standard ECMA-262: ECMAScript Language Specification" date: August 2017 target: http://www.ecma-international.org/publications/standards/Ecma-262.htm

because the Ecma-262.htm link will always contain information about the most current edition of the standard. Or perhaps use https://www.ecma-international.org/ecma-262/ which should always take you directly to the html version of the most current edition. In general, we want the revised RFC to have an edition-free reference to ECMA-262 which means use the current edition, whatever that might be.

Also note that the official name of the standards organization has been "Ecma International" for quite a few years.

In the [ECMA-262] 6th Edition of the EcmaScript language standard a new top level grammar was introduced for EcmaScript Modules. This now makes two possible top level grammars for any given Source Text of EcmaScript.

I recommend rewording this so you don't have to reference obsolete versions of ECMA-262. Maybe:

In order to formalize support for modular programs [ECMA-262] now defines two top-level goal symbols for the ECMAScript grammar. This means that (in the absence of additional information) there are two possible interpretations for any given ECMAScript Source Text.

(BTW, it seems to me that this and subsequent material makes a strong argument for the application/javascript+module. If MIME types are supposed to be the mechanism that conveys out-of-band info on how to interpret a document and out-of-band info is needed to choose the correct parsing goal symbol for ECMAScript documents then the MIME type needs to encode that info. The fact that HTML has another mechanism doesn't seem adequate because it doesn't account for non-HTML agents that need to use MIME types to transmit ECMAScript documents).

[bmeck]

@allenwb thanks, incorporated the rewording changes. The draft has also been updated to be more in scope of what @adamroach was expecting.

Do you want to propose +module or +goal={module,script} along with the other changes?

[domenic]

non-HTML agents that need to use MIME types to transmit ECMAScript documents

I would be interested to hear from such agents on if they plan to use such a signal. (Or indeed, I would be interested to hear examples of such agents at all.)

[bmeck]

I know there exists various systems that transmit source text over the wire, but am not sure they use MIME. I also don't know of any that support specifying the grammar of a given source text though. All I know of use a single grammar when transmitting source texts.

[bmeck]

@allenwb after some checks. +module would be problematic for browsers since it is a new MIME and would cause browsers which are already rolling this out to fail to load files. We could propose a new parameter of ; mode={module,script} or some such that is silently ignored as per RFC2046. However, since it is silently ignored I might say we defer that until we get an environment using MIME that would support it. Sending an ignored MIME parameter of text/javascript; mode=module would still execute in browsers for script tags of <script type=nomodule src=...>. Does deferring that seem ok, or would you want to add it preemptively?

[adamroach]

@bmeck --

I might say we defer that until we get an environment using MIME that would support it

Seems like a chicken-and-egg problem. Adding it here would seem to give those systems that want this level of hinting a means to do so without requiring them to first come up with something proprietary. Leave it out if you're concerned it's going to slow you down unnecessarily, but my personal opinion is that it would be a simple addition in this document to head off the need to make another registry change (in another document) later.

[allenwb]

I generally agree with @adamroach thoughts WRT to ; mode={module,script}.

[bmeck]

@allenwb ok, will add. did you want an explicit FunctionBody one as well (I think you have mentioned this in the past)? Or would stating that the message content could be parsed with any valid grammar production within the goal be enough?

[bmeck]

@allenwb is 73780d0 sufficient to close this? I left it open ended in case ECMA-262 ever adds more goals. I could not find a phrasing in ECMA-262 for these "top" level goals except in:

It defines a set of productions, starting from two alternative goal symbols Script and Module, that describe how sequences of tokens form syntactically correct independent components of ECMAScript programs.

But we might want to rephrase the description somehow that it would be shown to only be script and module for now.

[bmeck]

closing as fixed

[allenwb]

missed #1 (comment) but yes, 73780d0 seems fine.