In order to achieve its mission, it is the group’s goal to work with the membership and Working Groups of the W3C to specify the technologies that allows installed applications to effectively make use of the Web platform. This includes specifying application programming interfaces (APIs), URI schemes, and vocabularies for describing various aspects of Web applications, which enable these applications to be run locally on devices.
The members of the CG will do that by:
- Creating and maintaining specifications and test suites relevant to “packaged web apps” (e.g., the W3C Widget Family of Specifications).
- Gathering use cases and requirements from vendors relying on these technologies.
- Suggesting refinements or fixes to existing specifications to better meet the needs of this class of applications.
- Evangelizing specifications to vendors and development communities.
- Documenting how to best use open web standards to build “native web apps”.
- Documenting best practices and, where possible, make tools available to developers.
The Native Apps Community Group will develop specifications, and thus, there will be Essential Claims under the W3C Contributor License Agreement or Final Specification Agreement.
- Splash Screen
- A splash screen is a graphic that is shown to users while an application is loading in the background. The purpose of a splash screen is to give immediate feedback to a user that an application is launching, allowing normal application startup to occur in the background. It can also be used to inform the user about the expected orientation in which an application is supposed to be used. This specification standardizes how splash screens are declared so they can be used in applications.
- Widget Packaging and XML Configuration,
- XML Digital Signatures for Widgets,
- View-mode Media Feature,
- Widget Access Request Policy.
- Can run locally on a device (including, but not limited to mobile devices, desktops, and server-class machines).
- Can be deployed, or otherwise embedded, from a server.
- Can be transformed into other formats so that they may be run across multiple platforms.
Relationship with W3C Web Apps WG
For Web Apps WG widget specs currently in at Proposed Recommendation or Recommendation status, the Native Web Apps CG will provide input on errata and will work with the Web Apps WG on publishing any needed Edited Recommendations. See WebApps’ widget spec publication status for a list of the widget specs including
their publication status.
This currently applies to:
For Web Apps WG widget drafts that have not reached Proposed Recommendation status, technical work on these drafts will take place in the Native Web Application CG and will be passed to the Web Apps WG to move toward Recommendation Status.
The CG will handle any technical change requests originating from the Web Apps WG. This applies to:
Relationship with W3C WGs for future, new Native Web Apps CG specifications
For future W3C Native Web Apps CG specifications that W3C agrees to move to the Recommendation track, the Native Apps CG will work with a related W3C WG. The CG will provide drafts to the WG for each stage in the W3C Process and will respond to both WG and review comments. All technical work on the spec takes place in the CG. This could be with a new W3C WG, not necessarily the current Web Apps WG.
The scope of the Native Web Apps Community Group covers the technologies related to developing Web Applications that:
This includes markup for describing various aspects of such applications, programming interfaces, and even URI schemes.
This group operates under the rules of the Community and Business Group Process. Matters relating to copyright and patents are governed by the Community Contributor License Agreement (CLA). All discussions undertaken by the group adhere to the General Communications Policies.
For new work, the Community Group participants make an initial proposal based around use cases and requirements (a “Community Submission”), which is discussed with members of the group and other reviewers. Consensus is reached sending out “Call for Consensus” (CfC), which lasts 5 business days (may be extended over vacation periods or upon request with a valid reason), which gives members a chance to object to the inclusion of a work item to the charter. This means that new items can be added to the charter as needed, so long as the membership agrees. Work on an mew item can begin during the CFC, but does not become a deliverable of the group until consensus is reached.
If there is consensus reached that the “Community Submission” is something the CG should work on, then at least one Editor, Prototypist, and a Quality Assurer is allocated to undertake the task of creating a specification from the Community Submission (individuals may play more than one role). Once the roles are assigned, the specification work may begin. Members may swap roles.
The Editor(s) writes the specification while taking into account CG members feedback, and also their own research and feedback from sources such as blogs, forums, IRC, implementation experience, etc. Their role is to make sure they address everyone’s use cases, while keeping the specification consistent, on track, and free of scope-creep (along with the Chair, who may also decide what is in scope or not). The Editor has the power to make autonomous decisions about trivial aspects in a specification (i.e., to avoid bike shedding), but must keep the CG informed of any normative changes to the specification. All normative modifications and/or addendum must be justified with clear, transparent, use cases. To facilitate testability of specifications, it is strongly recommended that Editors follow the guidelines provided described in A Method for Writing Testable Conformance Requirements.
The Prototypist(s) implements the specification and provides feedback from an implementation perspective to the CG and to the Editor. The Prototypist relies on the Quality Assurer(s) to provide the tests to verify their prototype.
The Quality Assurer(s) designs and manages the systems and tests related to the specification. The goal of the Quality Assurer is to make sure that every conformance requirement in the specification is tested, all redundancy is removed, and that the specification is computationally verifiable and correct.
Members may be assigned, or may volunteer to, the role of Reviewer throughout the specification development process – although the specification may be reviewed at any time, the Editor may call for a Reviewer. A reviewer is expected to review the text of a specification for technical completeness, legibility, spelling mistakes, etc. Reviewers shall have all their issues addressed by the CG members or by the Editor and feedback shall be formally tracked. The working group shall track all issues in the issue tracker.
If a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Editor of a specification can make a decision on a matter. If further objections are raised on the matter by members or the public, the Chair will weight the evidence/arguments and propose a path forward. If one or more members still object, then a vote will be called within the group (allowing for remote asynchronous participation — using, for example, email and/or a web-based survey). Based on the outcome of the vote, the matter should then be considered resolved unless and until new information becomes available. Voting on objections is a matter of last resort and is expected to be used only under exceptional circumstances.
During development within the CG, there is one and only one Specification (though Editor’s may keep a separate source, from which a public specification is produced). The CG treats specifications as living documents: version and dates are bound to the allocated decentralized versioning system.