WebAssembly 2024-09-17 > 2024-10-03

[dschuff]

Name of your specification

WebAssembly

This is a request for transition for version 2.0 of all 3 WebAssembly specifications, namely the core spec, which defines the core code format and semantics;
the JS API specification, which provides a JavaScript API for interacting with WebAssembly; and the Web API specification, which describes the integration of WebAssembly with the broader web platform.

URL of your specification

https://www.w3.org/TR/wasm-core-2/
https://www.w3.org/TR/wasm-js-api-2/
https://www.w3.org/TR/wasm-web-api-2/

Does your specification include an Internationalization Considerations section?

• My specification includes an Internationalization Considerations section

When does the review need to be finished?

2024-10-10

What has changed since any previous review?

All of the analysis herein concerns the changes made since Wasm 1.0. These are listed
here and include the following extension
proposals:
Sign extension instructions; Non-trapping float-to-int conversions; multi-value block types and function results;
reference types, table instructions, and multiple tables; bulk memory and table instructions; SIMD vector instructions. Links to overviews of each proposal can be found in the proposal's respective github repo (these are listed here).

Please point to the results of your own self-review

WebAssembly/spec#1806

Where and how should the i18n WG raise issues?

https://github.com/WebAssembly/spec/issues

Pointer to any explainer for the spec

No response

Other comments

This is a request for transition for version 2.0 of all 3 WebAssembly specifications, namely the core spec, which defines the core code format and semantics;
the JS API specification, which provides a JavaScript API for interacting with WebAssembly; and the Web API specification, which describes the integration of WebAssembly with the broader web platform.

There is not an explainer for the entire spec (and in any case it is fairly large). Links to explainers/overviews for each
of the 5 proposals can be found in the proposal's respective github repo (these are listed here).

[aphillips]

Please note that, due to TPAC and the normal schedule of I18N teleconferences (Thursdays), the requested review date of 2024-10-01 will be difficult for us to achieve. Is there a specific reason for the short review deadline?

[dschuff]

We do have more proposals waiting to merge into the spec after it goes to CR, so I want to get it done as soon as we can, but there's nothing magical about that specific deadline; I will push the date back.
In the other bug you mentioned your next teleconference is October 3, would you be able to get us on your agenda for that meeting?

[aphillips]

The way the I18N process works internally is:

• the spec is assigned a shepherd, who is the person who coordinates the review (and generally does most of the work). That will happen for this spec in our 2024-09-19 call tomorrow.
• the reviewers read the specs and file any issues as "pending" in our repo w3c/i18n-activity. (If they find no issues, they will report this)
• every week specifications in the in review column of our Review Radar are reviewed, along with any pending issues.
  • pending issues are discussed and approved for filing with the spec's owning WG

So your spec will be "on the agenda" for 3 October, as it will be in review. If we don't find anything, you'll get confirmation of that then (and we'll move your request to "completed"). If we do find something, you'll get issues filed (and your request will appear under "awaiting comment resolution")

If we find an issue (or if your review request is not under "completed"), your transition will be blocked until it is addressed, which is why it's a good idea to get these reviews done early. Note the guidance in Document Review:

When you have published a First Public Working Draft, you should work through available "self-review" materials and request review of your results in at least the following areas. Long enough before you request a transition to CR, you should do the same again, identifying substantive specification changes since the first review.

Your request includes three specs (one long, one kind of medium length, and one short one). Even if there isn't a lick of I18N stuff in them, someone has to read and understand them all. We do this for every W3C spec. A two-week window, especially when we're all busy with TPAC for one of them, isn't reasonable.

We will do our best to help meet your schedule, but WGs really should be aware that horizontal review engagement needs to start from FPWD, not two weeks prior to TransReq 😄

@plehegar

[dschuff]

To be clear, the diff between version 1.0 (which is already a REC) and 2.0 is much smaller than the full doc. The core spec has a changelog linked above. If it would help I can also aggregate the explainers for the proposals that have gone in since the last REC; these would be markdown rather than in the form of diffs against the W3C format, but it will be more comprehensive than the changelog in the spec, and still easier to see the scope (and also to understand why basically every line of our self-review questionnaire is "N/A").

[dschuff]

For review convenience, here is a list of the explainers for the proposals that have gone into 2.0, compared to 1.0 (currently in REC state). These are informal descriptions of the proposed changes and are not canonical, but describe an overview of the feature and could be useful in determining whether there is anything of interest for horizontal reviewers.

Note again also that the core spec contains a list of additions since version 1.0 and summarizes the addition to the core spec. The table summarizes the effect on the JS spec. The Web spec is unchanged since 1.0

Explainer	Specs affected	JS Spec difference summary
Nontrapping float-int conversion	Core
Sign-extension operators	Core
Multi-value block and function returns	Core, JS	Multi-value returns can be passed into JS as JS Arrays
JS BigInt Integration	JS	Wasm i64 values can be passed to and from JS as BigInt values
Reference Types	Core, JS	References to JS objects can be passed to and from Wasm as externref values.
Bulk Memory and table instructions	Core
SIMD Vector instructions	Core

[aphillips]

@dschuff Thanks! This is super-helpful!

[aphillips]

Ah... in reviewing our records, I note that there was a process failure when WebAssembly went to REC the first time.

I18N has never reviewed this specification, according to my records. This (and some similar problems) actually resulted in a TransReq procedural change.

Because we have never reviewed this spec, we probably can't just look at the delta ☹. Note that there are two unclosed issues in our repo against your earlier work.

This does not mean that we won't try to meet your deadline. However, I don't think I18N will agree with the resolution of the existing issues linked above (we already don't agree with one of them).

[dschuff]

Thanks for pointing this out. It looks to me like WebAssembly/spec#830 and WebAssembly/spec#1618 are actually the same issue. i.e. allowing any UTF-8 encoded identifier in the text format.
(Actually, before I expand on this... I'm a bit confused; should we have this discussion here, or on WebAssembly/spec#1806?)

[dschuff]

I'll expand on this here anyway for now, I can always repeat the comment somewhere else.

First, about the WAT (webassembly text) format. The primary format for encoding WebAssembly modules is binary. The binary format allows any UTF-8-encodable string to name imports/exports, sections and in the auxiliary identifier name section. WebAssembly implementations actually do not even need to support the text format to be considered compliant (for example, web browsers do not support it).
The WAT format is primarily used by spec authors and implementers to write example modules and human-readable tests. It is never exposed to web users, and not expected to be exposed to web developers creating wasm modules either (developers' use of wasm is moderated by toolchains, e.g. a developer would write in their preferred programming language using whatever identifiers are allowed in that language, and these would be encoded by their toolchain into a wasm binary).

Up through wasm 2.0 (the current WD), only ASCII identifiers were allowed in the WAT format (making it asymmetric with the binary format). This has been fixed as part of the custom annotations proposal. This proposal has already advanced through the CG stage process and will be merged into the working wasm spec as soon as version 2.0 advances.

[dschuff]

Oh and regarding review of the whole document: I still don't actually think it will take a huge amount of time. It's a big document for sure, but the large majority of it concerns the abstract syntax of the language (section 2), validation over the syntax (section 3), and execution semantics (4); none of which concern the encoding or representation.