The mission of the System Applications Working Group is to define an runtime environment, security model, and associated APIs for building Web applications that integrate with a host operating system. While this runtime will have substantial overlap with the traditional browser-based runtime environment, it will have some important differences, being focused on Web applications that integrate more strongly with the host platform rather than traditional hosted web sites.
This working group differs from both the Web Applications Working Group and the Device APIs Working Group in that those working groups are focused on defining APIs that are safe to run in a browser environment. The work of these groups is complementary to the work of this group, but this working group will focus on functionality that is not necessarily appropriate for the "browse-by" web.
|End date||@@@TBD: 2 years after ratification|
|Confidentiality||Proceedings are Public|
(FTE %: 20)
|Usual Meeting Schedule||Teleconferences: none (only as needed)
Face-to-face: 2-3 per year (only as needed)
The System Applications Working Group aims to produce a runtime environment and a set of APIs that let applications integrate closely with the operating system's functionality using nothing but the Web platform. Creating the ability to produce applications relying solely on the web platform extends the reach of the Web to new places and opens the door to greater cooperation between the Web and the operating system.
The scope of the System Applications Working Group covers the technologies related to developing Web application that integrate closely with a host operating system, including a runtime environment (with both an execution model and a security model) as well as markup vocabularies and application programming interfaces for describing and controlling the applications interaction with the host operating system.
The working group will focus on those operating system interactions that cannot necessarily be exposed safely to Web applications executing in the traditional browser security model. The working group will consider a broad category of host operating systems, including those running on desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras, and other connected devices.
Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions. The group should adopt, refine and when needed, extend, existing practices where possible. The Working Group should also take into account the fact that some deliverables will most likely be tied to widely deployed platforms.
This Working Group’s deliverables must address issues of accessibility, internationalization, mobility, security and privacy.
Additionally, comprehensive test suites will be developed for each specification to ensure interoperability, and the group will create interoperability reports. The group will also maintain errata as required for the continued relevance and usefulness of the specifications it produces.
To advance to Proposed Recommendation, each specification is expected to have two independent implementations of all features defined in the specification, including implementation on a constrained device (e.g. mobile phone, TV, camera).
The working group will deliver the specifications listed below. In a number of cases, pointers have been provided to existing documents that address requirements similar to those of given deliverables. These are provided solely as aids to the reviewing process and should not presume that the cited documents will be submitted to W3C or that the deliverable developed by the group will take one of these for its starting point. In some cases, links are not provided. This should not be taken to entail that there is no prior work on this item, but simply that it may not be available in a form suitable for linking (in some of those cases further information can be obtained through the B2G WebAPI document).
Note that where applicable, the group is free to split the above deliverables into several smaller specifications that collectively address the same space, or conversely to join some of the above into a single specification.
Where practical, the API specifications should use the Web IDL formalism.
Each specification must contain a section detailing any known security and privacy implications for implementors, authors, and end users. The Working Group will actively seek security and privacy review on all its specifications.
The Working Group may also enter into joint Task Forces with other groups (in particular with the Web Applications and Device APIs Working Groups), to collaborate on the deliverables above if specifications cross group boundaries.
A comprehensive test suite for all features of a specification is necessary to ensure the specification’s robustness, consistency, and implementability, and to promote interoperability between User Agents. Therefore, each specification must have a companion test suite, which should be completed by the end of the Last Call phase, and must be completed, with an implementation report, before transition from Candidate Recommendation to Proposed Recommendation. Additional tests may be added to the test suite at any stage of the Recommendation track, and the maintenance of a implementation report is encouraged.
The Working Group may also document in a Working Group Note the useful design patterns shared by the APIs it is developing.
Other non-normative documents may be created such as:
Given sufficient resources, this Working Group should review other working groups’ deliverables that are identified as being relevant to the Working Group’s mission.
The Working Group will maintain an updated timeline of its deliverables on its home page.
The group will begin by reaching consensus and producing a rough FPWD draft of the Security Model and Execution Model documents inside of its first quarter. While the other deliverables should by no means wait for these two documents to be final and polished before proceeding, given that the design of the APIs will depend on the environment to which they are tailored it will be necessary to have a “checklist” consensus on the primary aspects of this environment that these two documents define.
Most of the API deliverables in this charter already benefit from at least one and often several existing implementations. As such, once the preceding step is executed it is expected that the production of specifications building on strong implementation experience and existing documentation can proceed at the pace of five FPWDs per quarter (until Q2 of the second year). Each of these specifications is then expected to reach CR inside of three quarters, with transition to Recommendation status supported by the adaptation of tests from existing platforms to these specifications.
This Working Group’s specifications depend upon some specifications being developed by other Working Groups for example the Web Applications Working Group’s Web IDL specification and several of the Device APIs Working Group's specifications.
This Working Group is not aware of any dependencies other Working Groups’ specifications have on this Working Group’s specifications.
This Working Group expects to maintain contacts with at least the following groups and Activities within W3C (in alphabetical order):
The following is a tentative list of external bodies the Working Group should collaborate with:
To be successful, this Working Group is expected to have 10 or more active participants for its duration, and to have the participation of the industry leaders in fields relevant to the specifications it produces.
The Chairs and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other participants.
For each specification the Working Group will name a Test Facilitator whose responsibility is to ensure that a Test Suite is made available.
Based on the input from the group participants, the Chairs may also decide to create task forces that allow more focused discussions for topics that require specific expertise.
This Working Group welcomes participation from non-Members. The group encourages questions and comments on its public mailing list, email@example.com, which is publicly archived and for which there is no formal requirement for participation. The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.
Most of the technical work of the group is done through discussions on the firstname.lastname@example.org, the group’s public mailing list. Editors’ drafts and their editing history is available from a public W3C Web site. The group’s action and issue tracking data is also public, as are the participants-approved minutes from all teleconferences and meetings.
In general the Working Group does not hold teleconferences, but a teleconference can be scheduled occasionally at the chairs' discretion if a specific topic seems to warrant synchronous discussion.
The group uses a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and participants of the group, for Member-only discussions in special cases when a particular participant requests such a discussion.
Information about the group (for example, details about deliverables, issues, actions, status, participants) is available from the System Applications Working Group home page.
As explained in the W3C Process Document (section 3.3), this group will seek to make decisions when there is consensus and with due process. The expectation is that 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 should put a question out for voting within the group (allowing for remote asynchronous participation—using, for example, email and/or web-based survey techniques) and record a decision, along with any objections. The matter should then be considered resolved unless and until new information becomes available.
Asynchronous decisions that are attained through the mailing list, possibly using a “Call for Consensus” process are preferred, but synchronous decisions made during a teleconference or a face-to-face meeting are valid provided that the topic they address was clearly outlined in a public agenda posted one week earlier so that non-participating parties have a chance to voice their views ahead of time.
This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.
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.
This charter for this Working Group has been created according to section 6.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.