Client and Server JavaScript APIs Community Group Charter

Goals

The goal of the Client and Server JavaScript APIs Community Group (CG) is to  … . In order to achieve this mission, the CG will bring developers, W3C members, server vendors, operators and other relevant members of the industry together to:

1. Agree on core features developers can depend on. These will be defined by reference to a variety of other specifications from the W3C and other standards bodies.
2. Compile related conformance test suites.
3. Provide to W3C (and non-W3C) groups use cases, scenarios, and other input to drive successful client/server code interoperability.

Deliverables

The CG will produce the following types of deliverables:

1. Use Cases for other W3C (or non-W3C) groups
   Since participants will reflect diverse interests within the browser or server ecosystem, the CG plans to document a variety of (non-normative) use cases, scenarios, and other inputs. These may serve as input to other W3C (or non-W3C) groups.
2. Proposals for other W3C groups
   The CG will develop proposals for W3C Group to consider more server-side usage of the specified APIs they are working on, either synchronously or asynchronously. 
   Note: if some working groups prefer not to integrate a synchronous version of some of their API (usable in Worker contexts), one might be proposed on the CG wiki to cover at least the synchronous SSJS implementations requirements.
3. Test suites
   The CG will compile accompanying test suites for each recommendation it releases. Where required, the test suites will draw on pre-existing tests developed for the feature’s original specification. Otherwise, CG participants will endeavor to fill in the gaps. Since test case development may drive normative changes or clarifications into the original specifications, any new tests will be contributed back to the appropriate W3C (or non-W3C) group by their original author.
   Tests contributed to the W3C will be governed by the “Policies for Contribution of Test Cases to W3C”. Test suites will be distributed under the “Licenses for W3C Test Suites”.
   Note: some server-specific tests may be proposed to be added in existing tests suites. This group may, at least temporarily, host any of these additional tests if they are not approved for being integrated in the original API specification by the related working group (ex: considered to SSJS oriented).
4. Recommendations
   The CG will develop recommendations for server-side implementors to have them implementing as much as possible compatible environment to make JS libraries compatible on the client and the server. Multiple levels of the recommendations will be published and each successive level will build on the previous one by adding new features. All normative content will be specified exclusively by reference to the original standard defining the feature. Additional non-normative implementation guidance may be included. Because the Contributor License Agreement (CLA) states that material included by reference does not constitute Essential Claims, there will be no new patent licensing commitments for participants of this group. The community may suggest these specifications be taken up on the W3C standards track.

Indicative criteria for the inclusion of features in the Guidelines/Proposals/Recommendations

These are some of the indicative criteria which the CG will use to select use cases to be considered in the Guidelines or Recommendations:

1. The use case already impact a lot of implementations,
2. It is necessary for building a class of applications that has significant market share in native mobile environments,
3. It is significantly related to maintainability
4. It significantly lowers developer cost.

Features whose implementation is compromised by substantial obstacles (such as known security problems or patent licensing issues) will very likely not be included in a specification until the issues have been resolved.

The CG will aim to carefully balance developer needs and implementation constraints to ensure timely progress of the Specification.

Decision policy

The decision policy is as follows:

1. Chair puts a question.
2. Chair endeavors to make decisions by consensus but is empowered to make decisions even where there are objections.
3. Chair has responsibility to ensure that all questions put to the group, all decisions, and all objections are publicly documented.
4. People who have material new information may request the Chair reopen a question.

It is the Chair’s responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.