Service Workers Working Group Charter
The mission of the Service Workers Working Group is to enable Web applications to take advantage of persistent background processing, including hooks to enable bootstrapping of web applications while offline.
| Start date | 2 August 2017 |
|---|---|
| End date | 31 January 2020 |
| Charter extension | See Change History. |
| Chairs |
|
| Team Contacts | Mike Smith, Yves Lafon (0.1 FTE) |
| Meeting Schedule | Teleconferences: Teleconferences will be
held approximately monthly. Face-to-face: The Working Group will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings will be scheduled by consent of the participants, 2 or 3 times per year. |
Scope
Web Applications traditionally assume that the network is reachable, which is not always the case. The Working Group will specify event-driven services between the network layer and the application, allowing it to handle network requests gracefully even while offline.
Success Criteria
In order to advance to Proposed Recommendation, each specification is expected to have at least two independent implementations of each 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 have an associated testing plan developed in parallel, and complete by the time the specification reaches Candidate Recommendation; by Recommendation, there should be a test suite for each deliverable, sufficiently broad to demonstrate interoperability.
Each specification should have implementation reports showing adoption, fostering the ready availability of multiple, independent, interoperable implementations, including in browsers, authoring, and validation tools, and usage on the Web.
If a critical mass of key stakeholders and implementers of this technology do not join the group, its charter should be re-examined by the W3C.
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 Working Group will deliver the following W3C normative specifications:
- Service Workers
-
This specification defines an API.
Draft state: Working Draft
Expected completion: Version 1, Q4 2017
- Adopted Working Draft:
- Service Workers, November 10, 2016.
- Reference Draft:
- Service Workers, November 10, 2016, produced under the Web Platform Working Group.
The Working Group may deliver the following W3C normative specifications:
- Background Synchronisation
-
This specification defines an API that uses Service Workers to permit both one-off and periodic synchronisation of data, for applications that use non-local data storage.
The Working group may produce multiple versions of each deliverable, reflecting developments in how much of the relevant technology is interoperably implemented.
The working group intends to use a parallel specification-editing and -testing approach, where all normative specification changes are generally expected to have a corresponding test change, either in the form of new tests or modifications to existing tests, or must include the rationale for why test updates are not required for the proposed update.
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
- September 2017: First teleconference
- October 2017: Service Workers 1 Candidate Recommendation
- October 2017: FPWD for Service Workers 2
- 2019: Service Workers 2
- March 2019: Proposal for rechartering or closing the Working Group
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
- Web Platform Working Group
- This group enables improved client-side application development on the Web, including application programming interfaces (APIs) for client-side development.
- Web Performance Working Group
- This group provides methods to measure and improve aspects of application performance of user agent features and APIs.
- Web Application Security Working Group
- This group develops security and policy mechanisms to improve the security of Web Applications, and enable secure cross-origin communication.
External Groups
TC39 - ECMAScript Standards BodyParticipation
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 working 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, subject to contributors' agreement to the terms of the W3C Patent Policy.
Communication
Technical discussions for this Working Group are conducted in public: 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 may 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 Service Workers Working Group home page.
Working Group teleconferences will focus on discussion of particular issues, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on GitHub issues. The public is invited to review, discuss, and subject to agreement to the terms of the W3C Patent Policy 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). For technical decisions, an editor or other participant typically 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.
If consensus is not achieved after careful consideration of the range of views presented but a decision is necessary for timely progress, the Chairs may call for a vote, in accordance with the W3C Process Document (Section 3.4, Votes) and the process for asynchronous resolution described in the following paragraphs in which case they will record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution including requests for transition of document states decisions taken in a face-to-face meeting or teleconference will be considered provisional.
Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional until 10 (ten) working days after the publication of the resolutions in meeting minutes on the working group's mailing list.
A call for consensus (CfC) will be issued for all resolutions not proposed at a teleconference or face to face meeting with a response period of at least one week, based 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
2019/12/19: Charter extended until 31 January 2020
The Service Workers specification was originally chartered as a deliverable of the Web Applications Working Group in its charter for 2014-2016. When that group was merged into the Web Platform Working Group, the deliverable was maintained in its first and second charters.
The Background Synchronisation proposal has been developed in the W3C's Web Platform Incubator Group
This charter brings the Service Worker specification to a new Working Group, and proposes the Background Synchronization specification a W3C Recommendation-track deliverable, according to the W3C Process Document (section 5.2.3).