Rich Web Application Backplane Incubator Group Charter

Scope

We propose that common building blocks such as submission, data models, model-view binding and behavior, and web components can provide a common infrastructure for multiple markup formats. Further, we propose a common infrastructure for both declarative and imperative web programming languages. By aligning APIs and their declarative representations, we hope to support both implementation approaches and increase interoperability between them.

Submission

One element of the backplane should be a common approach to "submission" used in multiple Working Groups. In addition, we desire submission to have common behavior across both scripting and declarative programming models. We will explore a common set of events related to the submission lifecycle which can be driven by either script-based or declarative handlers.

Data model

The role of the data model is to serve as a bridge between end-users and the business services with which they interact. An intelligent data model can be seen as a mobile agent that carries with it selected business rules (e.g. bind statements in XForms).

It is important to stress that not all applications may require the full set of function outlined here. We propose a modularized definition of a data model for the Rich Web application backplane that includes the following features:

• Data instances: Support for storing data in one or more instances of a model, each sharing the metadata of that model (e.g. schema, constraints).
• Validation: Data models may also have associated validation rules, provided through XML Schema, Relax-NG, RDF, or other schema technologies. Validation rules may also be associated with instances using lightweight notations such as the type attribute in XForms for those applications not requiring full schema support or running on small platforms.
• Constraints: As a mobile agent, it is often important for data models to be augmented with business rules, for example constraining the values or structure of elements in the model as a function of data entered by the user, in order to support as much validation not just of syntactic aspects of data but selected semantics as well -- as close to the user as possible.
• Actions: May be declarative or script-based handlers to respond to model change events.

Events

Within W3C and outside, much use is being made of events and event handling. Specs such as HTML and XForms use events as the hook for adding interactive functionality, and defining the processing model through sequences of events.

Events are important to many groups, especially those related to interactive content. Groups that are clearly involved include: HTML, Forms, SVG, WAI, Voice, SYMM, DI, CDF and Web API. What is needed is a unified approach across W3C, preferably in a generic way so that compound documents can operate in a consistent manner.

Examples of topics that may be addressed in the events area include the following. Members of the XG will set priorities for examining these, and other event-related, issues during initial meetings.

• Device independence
• Accessible eventing
• Standard events for frequently occurring use cases.
• XML-generic markup for handlers
• Scripted and declarative handlers
• Methods for binding events and handlers
• Security issues when binding cross-document
• Cross-namespace issues in compound documents
• Integrating event approaches (such as merging SMIL and Voice/CCXML events with the DOM approach).

Backplane conformance, reuse, and composition

A key goal of the backplane is to support a loose coupling style of interaction among components. By plugging into the backplane, and listening to and raising data change events on it, web applications might be created with fewer dependencies on the internal design of their embedded components. New controller languages, like the State-Chart XML being defined in the Voice Browser WG, could further simplify the job of responding to events on the backplane and hence help web authoring become possible for increasing numbers of developers.

The Backplane XG will define a high-level architecture describing how the collection of common components identified above can be used together in such a loosely-coupled style. The architecture will include guidance for writing backplane-conforming applications in terms of the modularity of their artifacts -- addressing questions such as what's needed to "include" the backplane, what metadata is required for an application fragment wanting to "plug-in" to the backplane? Finally, we will look at approaches to support packaging backplane based markup fragments into reusable and distributable web components.