Declarative modelling of rich web apps

The basic premise is that there is plenty of market potential for tools and services that assist people with developing and maintaining rich web apps, whether for use in enterprise, B2B or B2C. This can be used to complement roll out of Service-Oriented Architecture (SOA). The primary benefits over traditional web authoring techniques include:

• reduced costs for development and maintenance
• improved security, accessibility and usability
• easier delivery to a wide range of devices and platforms including HTML, SVG, Flash, Silverlight, .NET and Java
• enabling business analysts to create apps through end-to-end models without having to go through IT departments and the associated geek barrier
• easier integration with SOA and enterprise knowledge management systems (business ontologies)

A layered architecture is needed:

1) Application tasks, data and meta-data
2) Application dialogue models (and history)
3) Abstract UI (modality and device independent)
4) Concrete UI (modality and device dependent)
5) Physical realisation for specific devices

XSLT provides an existing solution for transformations between layers, with the exception of the physical realization layer which may call for more complex compilation techniques, guided by author supplied policies.

More work is needed for declarative models of behavior. Two things spring to mind:

• SCXML for event driven state models
• means to raise events that mutate data or UI

The second strongly overlaps with remote events for XML (REX) and both use cases could be covered by a single new spec. This would have the benefit of allowing for distributed implementations where the UI is on a different device from the application logic. This relates to ideas for streaming XSLT.

XForms is relevant to the model meta-data and to abstract UI. The ARIA roles, states and properties specs point to an opportunity for defining declarative markup and behavior for the concrete UI, perhaps as companion specs to XSL-FO.

If we can leverage ARIA, we can readily make the case for the ease of generating HTML for existing browsers, given that ARIA was designed to annotate HTML to enable greater usability of accessibility tools. This should satisfy any desire for a continuum from HTML4, but direct re-use of HTML4 form fields is fraught with problems and XForms provides a much better basis.

The OpenAjax Alliance is developing a registry for Ajax toolkits, and this could provide valuable insights as to the kinds of objects, states and events that developers are looking for.

For "skinning" the UI it would be worth evaluating whether to continue with CSS or to look at a pure XML solution in collaboration with the XSL working group, that can be translated into HTML and CSS when needed. Applying XML to constraint-based layout looks like an interesting route together with the means to expose the delivery context to XSLT. XBL2 looks like valuable mechanism for defining bindings to controls, e.g. to skin an abstract input control as a rotary dial defined in SVG and JavaScript.

Jose's presentation from the 25 October 2007 UWA telecon provides further details on the motivation for a layered architecture and potential next steps.

The Butler Group's (Datamonitor) report on Rich Web Applications provides a good assessment of the competitive landscape for authoring tools.