System Applications

From W3C Wiki
Revision as of 12:57, 7 March 2013 by Mcaceres (Talk | contribs)

Jump to: navigation, search

This is the wiki for discussions on System Applications in support of the System Applications Working Group, see the charter and the mailing list.

The aim is to define an run-time environment, security model, and associated APIs for building Web applications that integrate with a host operating system. While this run-time will have substantial overlap with the traditional browser-based run-time 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.

As an example, consider an API to enable access to information in your address book, whether this is stored on your device or in the cloud. For a regular web site, the API should give users explicit control over which information is made available to the web site, rather than giving it free access to everything. A system application API by contrast could be used to create and manage your address book. This requires a higher level of trust in the application code since the API would need to provide free access without the user prompts as required to preserve privacy in the weaker API.

How to get involved

Please subscribe to the public mailing list See the link on that page for details. If you have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the account request form.

In case of further questions, please contact the following:

  • Dave Raggett <>

Note: anyone making a substantive contribution to W3C specifications will be required to commit to the requirements of the W3C Patent Policy.

Editorial process

  • Once the WG has reached consensus on which of the proposed drafts to work on, each specification will be given its own repository on the SysApps Organization on Github.
  • Each repository will be named after the expected specification shortname. For example, a specification using 'foo' as a W3C shortname should be inside sysapps/foo and be accessible from Having each specification in its own repository provides both editors and interested parties a single palce to monitor changes and issues related to a particular specification.
  • On GitHub, please name your spec "index.html"; and, if using Anolis, please include the "index.src.html" file. This allows the specification to be automagically served by GitHub pages.
  • All specification text contributions are made via Pull Requests. We ask everyone to do this because every time a commit is made in the repo, and email will be generated. So, to avoid spamming the public mailing list, please fork the repositories into your own account and make pull requests from there.
  • Before submitting a pull request, please make sure you format your code. We recommend using [HTML5 Tidy]. This makes it easier for the integrator and WG members to review your code. For consistency, unformatted HTML code may be rejected.
  • At least one person per specification shall have commit access per repository. This person will serve as "integrator", which, reviews changes for editorial issues before any contribution is made into the specification. The integrator makes sure that editorial changes are consistent with the document (e.g., no spelling mistakes, that algorithms make sense, etc.). Major changes should have been discussed previously in the mailing-list in order to ascertain consensus. Thus, the the integrator's role is to make sure that all changes reflect the consensus of the working group.
  • Anyone can review and comment on pull requests. Active review from working group members is encouraged.
  • Each specification repository will be set up to only have a "gh-pages" branch. This reduces the amount of overhead because contributors directly pull to the correct branch and there is no need to merge from master to gh-pages. In addition, this allows the "unofficial editors' draft" to always be available.
  • Unofficial Editorial drafts will be available through the * domain name (e.g., This makes documents easy to find and link to. Marcos currently controls this domain, but is happy to donate it to the Working Group (or co-administer it). See "CNAME support for GitHub Pages".
  • Best effort should be made by editors to always direct technical discussions to the W3C public-sysapps mailing list.
  • Contributors are welcome to use the "on the fly" edit feature from GitHub to submit changes.
  • Trackbot is not going to be used.

Call for Proposals, Phase 1 (New deadline 1 January 2013)

We are inviting proposals and collecting them on github, see:

Please format your proposals as a W3C working drafts, and use the W3C Document License. For details on how to do this see Adam's email. Once your proposal is on github, please start a new thread on public-sysapps announcing your proposal, ideally with the name of the deliverable in the subject.

Working group participants should feel free to discuss proposals as they are submitted. After November 18th, we'll seek consensus about which of the proposals we want to publish as First Public Working Drafts. Based on our previous discussions, it seems likely that we'll receive multiple proposals for some deliverables. In those cases, the working group might want to combine multiple proposals into a single working draft.

Phase 1 drafts

Execution Model

Security Model

Alarm API

Contacts API

Messaging API

Telephony API

Raw Sockets API

Phase 2 drafts

Bluetooth API

Browser API

Calendar API

Device Capabilities API

Idle API

Media Storage API

Network Interface API

Secure Elements API

System Settings API

Face to Face Meeting

1st F2F Meetinig in Madrid (April 9-11, 2013)