[DRAFT] WebAssembly Working Group Charter
The mission of the WebAssembly Working Group is to standardize a portable, size- and load-time-efficient format suitable for compilation to the web.
| Start date | 01 May 2017 |
|---|---|
| End date | 01 May 2020 |
| Charter extension | See Change History. |
| Chairs |
|
| Team Contacts | public-webassembly@w3.org (0.1 FTE) |
| Meeting Schedule |
Teleconferences: we will meet by teleconference
approximately once per month. Meetings will be scheduled by
consent of the participants. Teleconferenced meetings will be
announced on the public mailing list with at least 3 days notice.
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. Face-to-face meetings will be announced on the public mailing list with at least 10 days notice. Teleconference access to face-to-face meetings will be made available. |
Note: The W3C Process Document (2015) requires “The level of confidentiality of the group's proceedings and deliverables”; however, it does not mandate where this appears. Since all W3C Working Groups should be chartered as public, this notice has been moved from the essentials table to the communication section.
Scope
Since the inception of the Web, various technologies have been developed to allow "native" applications on the Web. Techniques such as user consent with digital signatures and Virtual Machines with different capabilities than JavaScript failed to be robust in the face of increasingly high security requirements. Later efforts like Native Client, which featured robust security, failed to achieve cross-browser adoption. Cross-compilation to JavaScript using Emscripten, especially using the machine optimization subset called asm.js, achieved some degree of success. However, consistent cross-browser performance, shared memory threads, and other machine features have proved elusive.
The WebAssembly standard addresses the need for native performance code on the Web in applications ranging from 3D Games, to speech recognition, to codecs. It provides a standard portable, size- and load-time-efficient format that attempts to maximize performance, interoperate gracefully with JavaScript and the Web, while ensuring security. WebAssembly is also intended to be useful in other contexts in which a standard, portable format for high performance code is relevant.
By initially focusing on features more easily implemented in existing JavaScript engines, relying on JavaScript bindings to Web APIs, and deferring subtle features such as threads to later versions, WebAssembly attempts to quickly give developers access to more power in a fashion consistent with the Extensible Web Manifesto.
Success Criteria
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each of feature defined in the specification.
Each specification should contain a section detailing any known security or privacy implications for implementers, Web authors, and end users.
Each specification should contain a section describing known impacts on accessibility to users with disabilities, ways the specification features address them, and recommendations for minimizing accessibility problems in implementation.
Deliverables
More detailed milestones and updated publication schedules are available on the group publication status page.
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
Normative Specifications
The WebAssembly Working Group will deliver the following W3C normative specifications:
- WebAssembly v.1
-
This specification defines portable, size- and load-time-efficient format suitable for compilation to the web. An OCaml reference interpreter and a compliance test suite may also be provided.
Draft state: Adopted from WebAssembly CG
Expected completion: Q4 2017
- Multiple return values
- Multiple memories + tables
- Threads + shared memory
- SIMD
- DOM/HTML inter-operation
- Garbage collected object support
- WebIDL interpretation for direct binding
- Direct WebGL binding
- Direct memory mapped write access to IndexedDB objects
Other Deliverables
Other non-normative documents may be created such as:
- Use case and requirement documents;
- Test suite and implementation report for the specification;
- Primer or Best Practice documents to support web developers when designing applications.
Timeline
- Q2 2017: First Public Working Draft of WebAssembly v.1
- Q3 2017: Candidate Recommendation of WebAssembly v.1
- Q4 2017: First Public Working Draft of WebAssembly v.2
- Q1 2018: Candidate Recommendation of WebAssembly v.2
- Q2 2018: First Public Working Draft of WebAssembly v.3
- Q3 2018: Candidate Recommendation of WebAssembly v.3
- Q4 2018: First Public Working Draft of WebAssembly v.4
- Q1 2019: Candidate Recommendation of WebAssembly v.4
- Q4 2019: First Public Working Draft of WebAssembly v.5
- Q1 2019: Candidate Recommendation of WebAssembly v.5
- Q2 2019: First Public Working Draft of WebAssembly v.6
- Q3 2019: Candidate Recommendation of WebAssembly v.6
- Q4 2019: First Public Working Draft of WebAssembly v.7
- Q1 2020: Candidate Recommendation of WebAssembly v.7
Coordination
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD and CR, and should be issued when major changes occur in a specification.
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
W3C Groups
- WebAssembly Community Group
- Community Group will provide seed specification to begin the standards process.
- Web Applications Working Group
- Potentially coordinate on serialization, direct write access, and WebAssembly bindings to IndexedDB.
- Web Platform Working Group
- Potentially collaborate on WebAssembly specific bindings to Web APIs (or interpreting existing WebIDL as it relates to WebAssembly).
External Organizations
- TC39 - ECMAScript Standards Body
- Coordinate on integration with JavaScript, particularly on SharedArrayBuffer and its memory model
- Khronos Group
- Potentially collaborate on WebAssembly specific bindings to WebGL.
Participation
To be successful, this Working Group is expected to have 6 or more active participants for its duration, including representatives from the key implementors of this specification, and active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a day per week towards the Working Group. There is no minimum requirement for other Participants.
The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.
Communication
Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed on a public repository, and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the WebAssembly Working Group home page.
Most WebAssembly Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on the public mailing list public-webassembly@w3.org (archive) and on GitHub issues. The public is invited to review, discuss and contribute to this work.
Decision Policy
This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote, and record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.
This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.
Licensing
This Working Group will use the W3C Software and Document license for all its deliverables.
About this Charter
This charter has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Charter History
The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):
| Charter Period | Start Date | End Date | Changes |
|---|---|---|---|
| Initial Charter | 01 May 2017 | 01 May 2020 | new |