Web Applications Working Group Charter proposed
The mission of the Web Applications (WebApps) Working Group, part of the Rich Web Client Activity, is to provide specifications that enable improved client-side application development on the Web, including specifications both for application programming interfaces (APIs) for client-side development and for markup vocabularies for describing and controlling client-side application behavior.
| End date | 31 May 2014 |
|---|---|
| Confidentiality | Proceedings are Public |
| Chairs | Art Barstow Charles McCathieNevile |
| Team Contacts (FTE %: 30) |
Doug Schepers |
| Usual Meeting Schedule | Teleconferences: topic-specific calls
may be held up to once per week Face-to-face: we will meet during the W3C's annual Technical Plenary week; other additional F2F meetings may be scheduled (up to 2 per year) IRC: active participants, particularly editors, regularly use the #webapps W3C IRC channel |
Goals
As Web browsers and the Web engine components that power them become ubiquitous across a range of operating systems and devices, developers are increasingly using Web technologies to build applications and are relying on Web engines as application runtime environments. Examples of applications now commonly built using Web technologies include reservation systems, online shopping / auction sites, games, multimedia applications, maps, enterprise-specific applications, interactive design applications, and PIM (email, calendar, etc) systems.
The target environments for the Web Applications Working Group's deliverables include browsers on desktop, mobile devices such as phones and tablets, televisions, and other devices, as well as non-browser environments that make use of Web technologies. The group seeks to promote universal access to Web applications across a wide range of devices and among a diversity of users, including users with particular accessibility needs. The APIs must provide generic and consistent interoperability and integration among all target formats, such HTML, XHTML, and SVG.
Scope
This charter extends the second Web Applications Working Group Charter to produce deliverables necessary for the evolving Web application market, and continue work already in progress.
The scope of the Web Applications Working Group covers the technologies related to developing client-side applications on the Web, including both markup vocabularies for describing and controlling client-side application behavior and programming interfaces for client-side development.
Additionally, server-side APIs for support of client-side functionality may be defined as needed.
Web Applications Working Group specifications are expected to be applicable to an array of target formats — including HTML, XHTML, SVG, DAISY, MathML, SMIL, and other DOM-related technology. Although the primary focus will be handling of content deployed over the Web, the deliverables of the Web Applications Working Group should take into consideration uses of Web technologies for other purposes, such as building user interfaces on devices.
The Web Applications Working 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. It is reasonable for the Working Group to deliver APIs optimized for particular languages, such as ECMAScript. Interfaces for other languages such as Java, Python, C# and Ruby, may be developed in cooperation with the organizations responsible for those languages.
Furthermore, the Web Applications Working Group deliverables must address issues of accessibility, internationalization, mobility, security, and privacy.
Testing plays an important role in improving the current state of Web applications. Comprehensive test suites will be developed for each specification to ensure interoperability, and the group will assist in the production of interoperability reports. The group will also maintain errata as required for the continued relevance and usefulness of the specifications it produces.
Members of the Web Application Working Group should review other working groups' deliverables that are identified as being relevant to Web Applications Working Group mission.
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.
Deliverables
Recommendation-Track Deliverables
The working group will deliver at least the following:
- Behavioural extension mechanism
- A mechanism for adding custom elements to a document which allows them to have well-defined behaviour and rendering. This replaces the XML Binding Language (XBL2) deliverable from the previous charter. The XBL2 specification may be abandoned, with the Web Components specification replacing it to meet the requirements of this deliverable.
- Clipboard API and events
- A specification to expose common clipboard operations such as cut, copy and paste to Web Applications.
- Database and Offline Application APIs
- A set of objects and interfaces for client-side database
functionality. For more details, see the WebApps WG Database
API page. The following Database APIs are deliverables under
this charter:
- An API for a database of records holding simple values and hierarchical objects
- Storage Quota API
- An API for managing the amount of storage space (short- or long-term) available
- Web Storage
- An API for persistent data storage of key-value pair data in Web clients. This is in Candidate Recommendation.
- Document Object Model (DOM)
- A set of specifications defining objects and interfaces for
interaction with a document's tree model. These deliverables
include:
- DOM4
- A platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of documents, with specific considerations for the browser-based Web platform. This specification now includes DOM Mutation Observers, a replacement for the Asynchronous DOM Mutation Notification deliverable in the previous charter
- DOM Level 3 Events
- A generic platform- and language-neutral event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event.
- DOM Parsing and Serialization
- A specification describing how to parse into a DOM, and serialize for export, an HTML or XML fragment or document. This was initially developed in the WHAT-WG.
- File interaction APIs
- The APIs for interacting with file systems have currently been
divided into three separate specifications:
- File API
- An API that enables web applications to select file objects and accessing their data. This replaces the File Upload specification.
- File API: Directories and System
- An API that allows web applications to interact with a file tree located on the client.
- File API: Writer
- An API that enables web applications to write a file to the client.
- Fullscreen API
- An API allowing elements to request the full screen for display. (API only, excluding sections "Selectors" and "Rendering" of the document which will continue to be developed by the CSS WG either as separate specifications or as a joint deliverable)
- Input Method (IME) API
- An API to determine the input method being used, to improve the internationalisation of applications working with keyboard and text entry.
- Pointer Lock and Gamepad
- APIs which allow interaction with controllers currently not supported by web standards.
- Progress Events
- Event types used for monitoring progress of operations, for example of uploads and downloads. This specification is a Candidate Recommendation.
- Selectors API, Level 1 and Level 2
- An interface for matching and retrieving Element nodes in a DOM according to flexible criteria. Selectors API Level 1 is a Candidate Recommendation.
- Server-Sent Events
- An API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API may be extended to work with or include other push notification schemes such as Push SMS or the ability to wake a 'sleeping' application, as discussed on the working group mailing list.
- Secure Cross-Domain Resource Sharing
- Mechanisms for selective and secure cross-domain scripting. Currently, there are two different specifications for defining proposed mechanisms: Cross-Origin Resource Sharing (CORS) and From-Origin. These extend the Same Origin Policy so authors can permit safe cross-domain transactions.
- CORS is a joint deliverable with the Web Applications Security Working Group.
- URL API
- An API to work with the components of a URI in ECMAscript - host, scheme, port, etc.
- View Orientation API
- A view orientation and locking API e.g. to enable reading the view's orientation state, locking view orientation, notification of view orientation state changes, etc.
- Web Intents
- An API and associated markup to enable the discovery and registration of services which a web application can make use of according to a user's preferences.
- This is a joint deliverable with the DAP Working Group.
- Web Interface Definition Language (Web IDL)
- Language bindings and types for Web interface descriptions.
- Web Messaging
- A secure messaging system to allow discovery of and communication
between cross-domain documents, including
postMessageandMessageChannel. - Web Sockets API
- An API that enables Web pages to use the Web Sockets protocol for two-way communication with a remote host.
- This specification is a Candidate Recommendation
- Web Workers
- An API that allows Web application authors to spawn background workers running scripts in parallel to their main page, allowing for thread-like operation with message-passing as the coordination mechanism.
- Widgets
- The working group will continue to move Widget-related
deliverables from its previous charter toward Recommendation status.
The following widget specifications are not yet at Recommendation
status:
- The Widget Interface
- APIs to store preferences and access widget package metadata.
- XML Digital Signature for Widgets
- A means for widget packages to be digitally signed using a custom profile of the XML-Signature Syntax and Processing Specification.
- Widgets Updates
- A version control model that allows widgets to be kept up-to-date over [HTTP].
- Widgets URI Scheme
- a URI scheme for use inside widgets or other such applications of web technology that do not run on the Web.
- XMLHttpRequest (XHR)
- An API for client-server data transfer, both to specify what is currently implemented and to extend its capabilities.
Each specification must contain a section detailing any known security implications for implementers, Web authors, and end users. The WebApps WG will actively seek security, privacy, internationalisation and accessibility review on all its specifications.
Where a specification reaches Recommendation status the working group may begin work on, and deliver an updated version of the specification under this charter. Specifications may be moved to Recommendation and a subsequent version begun in order to facilitate the progress of other work which depends on a stable reference.
Updated specifications that the working group is fairly likely to
work on include the following:
- DOM5
- In order to satisfy dependencies and allow specifications which depend on DOM4 to move forward, the working group may produce a DOM4 specification and move unstable content to a new version which can supersede it.
- Widgets
- (As noted in section
3.1.1) A new version of Widget Packaging that allows the use
of JSON to describe Web Applications, which some browsers have
chosen to implement in place of the current XML-based standards. A Web
App packaging specification proposal has been offered by
Mozilla which may be used as a starting point for this work.The
proposal also includes an API for management of installed
applications.
For a detailed summary of the current list of deliverables, and an up-to-date timeline, see the WebApps WG Publication Status page.
3.1.1. Specification Maintenance
The working group will also maintain errata and new editions, as necessary, for the following Recommendation-status specifications:
- Element Traversal 1.0
- A lightweight interface for navigating between document elements.
- DOM Level 3 Core
- A platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of documents.
- Errata and new editions for other existing DOM specifications, as required.
- Widgets
- The working group will provide maintenance support for existing
recommendation, in collaboration with the Native Web Applications
Community Group. Currently, the following Widgets specifications are
(or are expected to be when this charter becomes operational)
Recommendations:
- The View Mode feature for Widgets
- A media feature and API related to presentation mode.
- Widgets Packaging and XML Configuration
- A packaging format and configuration format for widgets. The group may choose to update this work with other packaging and/or configuration syntax specifications, such as a JSON or plain-text format.
- Widgets Access Request Policy
- A means to request access to URI-identifiable resources (e.g. resources on the Web).
3.1.2 Abandoned work
Some deliverables from the previous charter will no longer be worked on.
- Programmable HTTP Caching and Serving
- An API for off-line serving of requests to HTTP resources using static and dynamic responses.
- Uniform Messaging Policy
- Web SQL Database
- An API for storing data in databases that can be queried using a variant of SQL. This specification has been published as a Working Group Note
- XMLHttpRequest (XHR), Level 1
- Work has stopped on this specification. What was known as XMLHttpRequest Level 2 has become the XMLHttpRequest specification.
- Widgets URI Scheme
- a URI scheme for use inside widgets or other such applications of
web technology that do not run on the Web. This specification has
been published as a Working Group Note.
3.1.2. Other Specifications
The market for applications of Web technologies continues to evolve quickly. Therefore, in addition to the specifications described in this charter, the Web Applications Working Group may take on additional specifications necessary to enable the creation of Web applications to meet the needs of the market as it evolves.
Specifically, because of the close relationship of the WebApps WG and the HTML WG in terms of participants, market, and community, the WebApps WG may opt to take on a limited number of specifications which were initially part of the HTML5 specification that have been split off for more general use with other languages. Consistent with W3C process, an Advisory Committee Review will evaluate whether the additional deliverable should be added to the WebApps WG charter. The expectation is that if the review is successful, Working Group participants will not be required to re-join the Working Group. For any work transferred to the WebApps WG, the first draft published in the WebApps WG is considered the first public Working Draft for application of the Patent Policy exclusion rules.
Other specification proposals may be identified by new submissions from Members, or by market research. These deliverables will require rechartering the Working Group.
For all new deliverables, the WebApps WG should develop an associated requirements section or document that identifies demonstrable use cases.
Other Deliverables
Other non-normative documents may be created such as:
- Test suites for each specification
- Primers for each specification
- Requirements document for new specifications
- Non-normative schemas for language formats
- Non-normative group notes
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.
Schedule
The working group maintains a page with its schedule expectations for deliverables. The indicative table below outlines aspirations for certain key specifications to reach Recommendation status:
| Specification |
Current Status |
Expected CR |
Recommendation |
Dependencies |
|---|---|---|---|---|
| CORS |
Working Draft |
2012 Q3 |
2012 Q4 |
HTML5 |
| DOM4 |
Working Draft |
2012 Q3 |
2013 Q1 |
|
| Indexed
DB |
Working Draft |
2012 Q3 |
2013 Q1 |
HTML5, DOM4, Web Workers |
| Selectors
API Level 1 |
Candidate Recommendation |
already |
Simultaneous with Web IDL |
WebIDL |
| Web IDL |
Candidate Recommendation |
already |
2012 Q3 |
|
| Web Messaging |
Last Call |
2012 Q3 |
2012 Q4 |
HTML5, WebIDL |
| Web Sockets |
Candidate Recommendation |
already |
2012 Q3? |
HTML5, WebIDL |
| Web Storage |
Candidate Recommendation |
already |
2012 Q3? |
HTML5, WebIDL |
| Web Workers |
Last Call |
2012 Q3 |
2012 Q4? |
HTML5, WebIDL |
Dependencies and Liaisons
Dependencies
A number of specifications depend on the WebIDL specification, which is therefore a very high priority for the Working Group.
In addition, some specifications are likely to depend on DOM4, which defines important aspects of DOM not covered in existing specifications as well as new features or changes from the existing standards that have become widespread in Web engines. It will therefore be important to produce a stable specification in a timely manner, which may necessitate moving content to a replacement specification (DOM5).
Several specifications have a dependency on the HTML 5 specification.
The Web Sockets specification has an effective dependency on the protocol defined by the IETF's HyBi Working Group.
Web Intents may have a close relationship to other discovery work being done in the Device APIs working group.
The Web Applications Working Group is not aware of any other Web Applications Working Group specifications that depend upon specifications developed by other groups.
However, the specifications of several other groups, such as HTML and SVG, depend upon particular Web Applications Working Group specifications, notably the DOM specifications. Where possible, additional dependencies will be avoided to prevent the disruption of dependent deliverables.
Liaisons
The Web Applications Working Group expects to maintain contacts with at least the following groups and Activities within W3C (in alphabetical order):
- Cascading Style Sheets Working Group
- To collaborate on the Selectors API and Fullscreen API specifications.
- Device APIs Working Group
- To coordinate regarding features for devices services such as Calendar, Contacts, Camera, etc., and to collaborate on the Web Intents specification.
- HTML (HyperText Markup Language) Working Group
- To monitor the development of the HTML specification as it complements the WebApps WG's specifications, and to help ensure HTML requirements for the WebApps WG's deliverables are met (noting that the HTML Working Group charter states specifically that the HTML Working Group will produce a specification for a language evolved from HTML4 and for describing the semantics of both Web documents and Web applications). In addition, to potentially form a joint task force with the HTML and SVG WG to specify the Canvas Graphics API, should the need arise.
- Internationalization Core Working Group
- This group may provide advice or review to ensure that WebApps WG deliverables meet the needs of an international Web. In particular the Working Group will request close review of the IME API.
- Privacy Interest Group
- The Working Group will request review of specifications and communication as necessary with this group.
- Protocols and Formats Working Group
- To ensure that WebApps WG deliverables support accessibility requirements.
- SVG (Scalable Vector Graphics) Working Group
- To monitor the development of the SVG specification as it complements the WebApps WG's specifications, and to help ensure SVG requirements for the WebApps WG's deliverables are met. In addition, to potentially form a joint task force with the HTML and SVG WG to specify the Canvas Graphics API, should the need arise.
- User Agent Accessibility Guidelines Working Group
- To ensure that WebApps WG deliverables support accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in deliverables of guidance for implementing WebApps deliverables in ways that support accessibility requirements.
- Web Applications Security Working Group
- As well as having a joint deliverable (CORS), this group has many overlapping interests with the WebApps WG.
- Web Performance Working Group
- This group focuses on performance of the Web platform, including deliverables of the WebApps WG.
Furthermore, the Web Applications Working Group expects to follow the following W3C Recommendations, Guidelines and Notes and, if necessary, to liaise with the communities behind the following documents:
External Groups
The following is a tentative list of external bodies the Working Group should collaborate with:
- ECMA Technical Committee 39 (TC39)
- This is the group responsible for ECMAScript standardization, and related ECMAScript features like E4X. As the Web Applications Working Group will be developing ECMAScript APIs, it should collaborate with TC39.
- Internet Engineering Task Force
- The IETF is responsible for defining robust and secure protocols for Internet functionality. A close relationship with the IETF HTTP group is crucial to ensuring the good design, deployment, and success of protocol-based APIs such as CORS and Web Sockets. This Working Group will rely upon review and parallel progress of associated specifications, and will keep pace with the IETF's HTTP and HyBi groups' work, conditional upon steady progress. The working group may well also liaise with the IETFs Web Security Working Group, either directly or through its liaison with the W3C's Web Applications Security Working Group.
Participation
To be successful, the Web Applications Working Group is expected to have 10 or more active participants for its duration, and to have the participation of industry leaders in fields relevant to the specifications it produces.
For each specification the Working Group will name a Test Facilitator whose responsibility is to ensure that a Test Suite is made available.
The Chairs, specification Editors and test Facilitators are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other Participants.
The Web Applications Working Group welcomes participation, with agreement from each participant to the provisions of the W3C Patent Policy.
Communication
The working mode of the group is described in detail on its wiki. In general the group does not hold teleconferences, and meets face to face at the TP/AC. It may hold more meetings, and certain specifications are developed with regular teleconferences. Note the Decision Policy below with regards to synchronous meetings.
Most of the technical work of the group will be done through discussions on one of the group's public mailing lists. Subscription to these lists is open to the public, subject to W3C norms of behavior.
- public-webapps@w3.org (archive) is used for general discussion and any topic not covered by a specific list.
- public-webapps-testsuite@w3.org (archive) for discussion of testing
- public-web-intents@w3.org (archive) for discussion of the Web Intents specification
- www-dom@w3.org (archive) for discussion of DOM specifications
- public-script-coord@w3.org (archive) for discussion of Web IDL and coordination with ECMA TC39
Editors within the group will use the W3C's public CVS repository or the Mercurial Repository to maintain Editor's Draft of specifications. The group's action and issue tracking data will also be public, as will the Member-approved minutes from all teleconferences.
The group uses a Member-confidential mailing list (member-webapps) for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a particular member requests such a discussion. There is also a Team-confidential mailing list for coordination between the Team and Chairs.
Up-to-date information about the group (for example, details about deliverables, issues, actions, status, participants) is available from the Web Applications Working Group home page.
Decision Policy
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.
Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional until 10 working days after the publication of the resolution in draft minutes sent to the working groups mailing list. If no objections are raised on the mailing list within that time, the resolution will be considered to have consensus as a resolution of the Working Group.
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.
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.
About this Charter
This charter for the Web Applications 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.
Changes from the previous Web Applications Working Group Charter
This section is informative
The following is a brief summary of the important changes to the charter.
- The following deliverables were explicitly added
-
- DOM4 and a possible DOM5
- DOM Parser / Serializer
- From-origin
- Fullscreen API (the API parts, with some parts of the overall technology being developed in the CSS working group)
- Gamepad
- IME API
- Mouse lock
- Storage Quota API
- URL API
- View Oreintation API
- Web Components
- Web Intents (Joint deliverable with DAP)
- Widgets specifications, especially Application packaging, may be
updated.
- Clarified
-
- ADMN replaced by DOM Mutation Observers which is in DOM4
- Clipboard Operations is now called Clipboard API and Events
- CORS is now a joint deliverable with the Web Application Security Working Group
- Dom level 4 Core is now called DOM4
- File APIs are three specifications
- Updated Widget specifications may be developed, most likely in
the area of packaging and configuration to allow for the use of
JSON and to describe existing Web Applications
- XBL2 is likely to be replaced by Web Components
- Moved to Maintenance
-
- Widget recommendations:
- Packaging and Configuration (but a new non-XML version might also be published)
- View Modes
- WARP
- Widget recommendations:
- Removed due to abandoning work
-
- Programmable HTTP Caching and Serving
- Uniform Messaging Policy
- Web SQL Database
- The Widget URI scheme
- XMLHttpRequest Level 1
Doug Schepers, <schepers@w3.org>, Team Contact
Art Barstow, Nokia, Chair
Charles McCathieNevile, Opera, Chair
Copyright© 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved.
$Date: 2012/04/20 15:39:54 $