DFAUI .- Declarative Format for Applications and User Interfaces
Use Cases and Requirements
Version 1.0

Abstract

The charter of the Web Application Formats (WAF) Working Group includes a specification for a declarative language for application and user interfaces (DFAUI). This document describes use cases and high-level requirements for this declarative language and thus will be an input when creating a specification for a DFAUI.

This document is purely informational and contains no conformance statements or testable assertions.

The WAF Working Group provides these requirements for general information and as of the date of its publication makes no commitment that any of the requirements will be satisfied in a follow-on specification for a DFAUI.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the first public working draft of the Declarative Application and User Interface Language Use Cases and Requirements document. It has been produced by the Web Application Formats (WAF) Working Group (WG). This WG is part of the Rich Web Clients Activity and this activity is within the W3C's Interaction Domain

This document is purely informational and contains no testable assertions. However, inputs standardizing DFAUI should attempt to conform, to the best of their ability, to the Requirements.

The public is encouraged to send comments to the WAF Working Group's public mailing list public-appformats@w3.org .

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy..

Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Color Conventions used

     Added text (not yet reviewed by the group)

     Removed text (not yet reviewed by the group)

     Changed text (not yet reviewed by the group)

Table of Contents

1 Introduction
  1.1 Terminology
  1.2 Target Audience
     1.2.1 Authoring Tools
     1.2.2 User Agents
2 Use Cases
  2.1 Use Cases Related to DFAUI User Agent Implementation
    2.1.1 UC1 - Device Independence
  2.2 Use Cases Related to Application Authoring and Deployment
    2.2.1 UC2 - Manual Authoring
    2.2.2 UC3 - Dynamic Generation
   2.2.3 UC4 - Incremental Download
   2.2.4 UC5 - Full Download
  2.3 Use Cases Related to Functionality and Business Problems
    2.3.1 UC6 - Client/Server Desktop Application Migration to Web
    2.3.2 UC7 - Enhancing an Existing Web Application
    2.3.3 UC8 - Look and Feel Customization
    2.3.4 UC9 - Separation of User Interface and Application Logic Authoring
    2.3.5 UC10 - Multiple Views
    2.3.6 UC11 - Application to be deployed in multiple devices
3 Requirements
  3.1 General
  3.2 User Interface Component Set
  3.3 User Interface Containers
  3.4 User Interface Interaction
  3.5 Layout Managers
  3.6 Application Logic
  3.7 Events
  3.8 Style Sheet
  3.9 Data Binding
  3.10 Validation
  3.11 Formatting
  3.12 Data sources
  3.13 Model API

Appendices

A References
B Acknowledgements

1 Introduction

The Web was initially developed for handling hyper-text documents. Its user interface is primarily based on HTML and its variants, which are fine for document browsing. However, as the web has become used more and more for applications, there is a need to create specifications that fill functional gaps in relevant specifications and to codify i.e. standardize existing practices.

Application user interfaces typically require a wider range of user interface components than standard HTML, such as menu, toolbar, window, dialog, tab box, etc. Secondly, applications are typically stateful e.g. partial screen update is more common than full page refresh. An application has its own life cycle independent of individual screens, such as application initialization and exit.

Due to the document-centric nature of HTML, only page-oriented user interfaces are developed to run in a web environment. More sophisticated user interface development have so far largely relied on thick client technologies such as Visual Basic, PowerBuilder, operating systems native API and Java GUI APIs. These thick client technologies have significant client environment dependency, and require client side download and installation , significantly increasing the cost and complexity for application deployment and maintenance. In a mobile environment, the problem is even worse due to additional network and client device limitations.

In the recent years, "Rich Internet Application" (RIA) has emerged. RIA refers to a new generation of web applications that delivers the benefits of thick client and web thin client[1][2]. There are different technical approaches for developing RIAs, including Java, .NET, Flash and Ajax[2][3]. In particular, Ajax became a widely accepted term due to applications like GoogleMaps. Though GoogleMaps runs on browsers today, it relies on scripting (several hundreds of kilobytes of Javascripts) to fill in the gap. Most of the RIA toolkits fill in the gap by employing a declarative markup language to reduce the need for scripting.

One of the significant drivers for DFAUI is Client/Server migration to Web, including a variety of applications such as PowerBuilder applications, Visual Basic applications, Native OS API applications (X-Windows, Win32/MFC) and Java GUI applications. Client/Server has been the mainstream technology for developing applications over the last twenty years. As a result, a lot of applications are based on Client/Server. They typically feature a rich graphical user interface. There is a significant trend in the industry to move away from Client/Server to the web environment, but there is a strong demand to do so without losing the richness and functionality that users have been used to.

Another significant driver for DFAUI is the necessity of abstract description mechanisms that allow a programmer to define the user interface of applications independently of the target device and platform. The availability of a DFAUI will enable the development of user interfaces once for all kind of devices implementing the principle of "single authoring-multiple adaptation" defined in the W3C Device Independence Guidelines.

1.1 Terminology

User interface

is the aggregate of means by which people (the users) interact with a particular machine, device, computer program or other complex tool (the system). The user interface provides means of:

• Input, allowing the users to control the system.
• Output, allowing the system to produce the effects of the users' manipulation.

The user interface (of a computer program) refers to the graphical, textual and auditory information the program presents to the user, and the control sequences (such as keystrokes with the computer keyboard, movements of the computer mouse, and selections with the touchscreen) the user employs to control the program

Graphical User interface

A graphical user interface (or GUI, often pronounced "gooey") , is a particular case of user interface for interacting with a computer or handheld device which employs different graphical elements such as images and visual controls (also known as user interface components or widgets) in addition to text to represent the information and actions available to the user. Usually the actions are performed through direct manipulation of the graphical elements.

User Interface Component

is a GUI element that a computer user interacts with. It is also known as a control or a widget. GUIs are composed of UI components. User interface components display information and allow the user to enter more information that the system will process. Two common examples of user interface components are text boxes and buttons.

User interface container

is a GUI element that can hold child UI components and to which you may add layout managers and other visual elements (including both containers and UI components) in order to create the application’s visual appearance. A container typically has a rectangular shape and absolute or relative dimensions. The container is responsible for defining the positioning and size of its user interface components. The policies for the positioning and size of the different commponents are established by the layout manager bound to each container.

The layout manager

is responsible for positioning and sizing the different user interface components that belong to a container. There can be different kinds of layout managers depending on the different policies for positioning and resizing the UI components. For example, a layout manager with the "vertical" policy will situate the UI components in vertical orientation. A layout manager always positions UI components relative to its container

Model

is the set of data that a user interface is managing in a certain moment. The model contains the domain-specific representation of the information on which the application operates. The data that comprise the model can be stored at different scopes which determine its lifetime. Typically there are three scopes: Application, Session and Default. All the data elements stored at the application scope remain during the whole lifetime of the application and are the same independently of the different users. All the data elements stored at the session scope remain during the lifetime of the user session. One example of a data element that typically is stored at session scope is the preferred language for the user or the user profile. The default scope is where the data elements that are not scoped at application or session are left.

Data Context

is the data structure that stores all the data elements that comprise the model. Each data element of the model typically has an identifier.

Expression Language

is a language that allow a programmer to address portions of a data structure or document using a declarative expression syntax and without writing any code. For instance, XPATH is an expression language intended to locate portions of DOM trees. JSP 2.0 E.L. is an expression language that enables the access to Java data structures and Java Beans.

Data binding

is a technique to associate data from the model to a user interface component in a declarative manner. Data binding is the glue between the view and the model. Data binding avoids writing code to populate the UI components with the data coming from the model and viceversa. A binding consists of an expression (written following the syntax of the expression language used) that address which data element coming from the model will be used to perform the binding. Using data binding the changes in the model are automatically reflected in the view and the new data entered by the user in the view can be automatically reflected in the model. There can be different types of bindings:

• One time data binding. it means that one and only one time the binding applies, and then the control is disconnected from the datasource i.e if the data changes, the UI will not get updated. Similarly, if a user modifies a data value in a UI component, the change will not propagate to the underlying data.
• One way data binding. A UI element gets populated with the data retrieved from a model data element. When the data changes, the UI will automatically refresh to reflect the changes. If a user modifies a data value in a UI component, the change will not propagate to the underlying data.
• Two way data binding. A UI element gets populated with the data retrieved from a the model. When the data changes, the UI will automatically refresh to reflect the changes. If a user modifies a data value in a UI component, the change will also propagate to the underlying data.

DFAUI

is a declarative language for application user interfaces.

DFAUI construct

is an element of the DFAUI language.

DFAUI authoring unit

is a set of DFAUI constructs considered as a unit from the standpoint of its authors.

DFAUI application

is an application that is developed using the DFAUI.

Binding definition

is a DFAUI construct to define all the parameters that comprise a binding i.e. the binding variable (defined using an expression language), the type of binding, etc.

Binding

is a DFAUI construct that links a binding definition to a UI component.

Input Validator

is a DFAUI construct that contains the logic to constraint the input made by the user. A validator can be specified declaratively or by providing a function written in a programming language that will check user input. Some input validators may check single inputs other may check multiple inputs.

Validator Chain

is a set of input validators to be checked sequentially. The validation will be successful if and only if all the validators in the chain are satisfied.

Validation

is a DFAUI construct that links an input validator or validator chain to a UI component.

Format

is a DFAUI construct to specify how the data (i.e. a date, a number, etc.) will be presented.

Data source

is a DFAUI construct that defines the source of some model's data, i.e a URL, an XML file, etc.

1.2 Target Audience

1.2.1 Authoring Tools

• Hand editing with a text editor.
• Dynamic generation via Web servers or other back end systems.
• Via authoring tools that support visual DFAUI development.

• Application-centric authoring tools to create user interfaces.
• Form-centric authoring tools to create data templates.
• Device-independent authoring tools for creating user interfaces that can be adapted to different user devices.

1.2.2 User Agents

• Via native support within a web browser that supports DFAUI specification.
• Via a browser extension module such as a plug-in.
• UA is a an Ajax library that runs inside a web browser.
• Via a dedicated DFAUI user agent that is independent of a web browser, implemented using J2SE or J2ME that runs inside a JVM, .NET that runs inside CLR or a native destkop program that runs on an opearting system, etc.
• Via a set of runtime libraries that execute at the server side and deal with rendering and binding.

2 Use Cases

This section describes several Use Cases for DFAUI. The Use Cases are grouped under three catogeries:

• Use Cases related to DFAUI User Agent.
• Use Cases related to Application Development Using DFAUI.
• Use Cases related to DFAUI Functionality and Business Problems.

2.1 Use Cases Related to DFAUI User Agents

2.1.1 UC1 - Device Independence

2.2 Use Cases Related to Application Authoring and Deployment

2.2.1 UC2 - Manual Authoring

2.2.2 UC3 - Dynamic Generation

2.2.3 UC4 - Incremental Download

2.2.4 UC5 - Full Download

2.3 Use Cases Related to Functionality and Business Problems

2.3.1 UC6 - Client/Server Desktop Application Migration to Web

A desktop based order management application needs to be moved to the web environment to reduce the cost of deployment and maintenance. The goal of the migration is to make the new web application behave as identical as possible to the current desktop application to avoid the cost of re-training thousands of users.

From a user interface perspective, the order management application is a typical desktop application: it features a menu bar that has drop down menus, a tool bar that users can click to perform actions, a Multiple Document Interface (MDI) that each child window presents a form: order entry, order query, user account information etc. The entire application is designed to enable mouse-less operation. Business users use this application to do their job every day. A lot of users are call-center agents. The call center agents will take calls from customers, place orders or modify orders on behalf of customers, and perform the entire operation using only keyboard for efficiency reasons.

2.3.2 UC7 - Enhancing an Existing Web Application

A global hotel chain has an existing web application used by hotel employees to manage individual hotel properties such as room rate, vacancy, promotion and reservations. Over the course of the years, the application has grown to handle more and more data. Users started to complain about significant performance issues as the amount of data grew. For example, if the user wants to sort all guest room according to room rate, the request has to be sent to the server side and an entire new table of sorted guest rooms has to be re-sent to the browser for rendering. For a hotel with hundreds of rooms or even thousands of rooms, this can be a very slow operation.

The hotel chain wants to fix the performance problem. They want to have smarter user interface widgets that behave more like native desktop user interface components. For example, a table widget would know how to perform sorting on the client side without doing a server round trip. Further, they want to find a way to perform incremental updates without incurring the cost of full reload.

2.3.3 UC8 - Look and Feel Customization

An independent software vendor (ISV) is in the business of developing and selling human resources management applications. Most customers are global 5000 companies. Though customers love the functionality of the software, each customer demands a customized look and feel that conforms to the customer's corporate brand identity.

To meet the need, the ISV is looking for a way that they can easily customize the application's look and feel. Ideally, they wish there is a single document that can be customized and only this document needs to be modified in order to customize the look and feel of the application.

2.3.4 UC9 - Separation of User Interface and Application Logic

John is an IT manager at an insurance company. John manages a team responsible for developing internal business applications. Over the last five to ten years, John has evolved his team based on his realization that very few people can be good at both UI design and programming. His team contains two user interface designers, who are very good at creating user interface screens and specifying the look and feel of these screens. The user interface designers do not have skills in writing procedure code. The tools that they use are graphic design tools. On the other side, John's team has ten developers that are good at writing application logic using a variety of programming languages such as Java and JavaScript. The tools they use are development tools such as Eclipse IDE.

2.3.5 UC10 - Multiple Views

A financial service firm wants to re-architect its financial trading application as a web application so that portfolio managers can access the application from anywhere. The application contains user interface for different tasks: trading, news, charting, market data feed and accounts information etc. Users need to be able to quickly switch between different tasks and navigate to different fields inside different views.

2.3.6 UC11 - Application to be deployed in multiple devices

A telco company owns a workforce management system. There is a new requirement that has to do with the automation of the field work done by that workforce, i.e the work that imply a travel to the client house. (for instance, installing an ADSL line). The requirements are that the technician should be able to know everytime the different tasks he has been assigned. Also the technician should be able to report the finalization of the tasks at the same moment that tasks are done. To resolve the problem the designers of the system decide to provide a mobile access channel to the workforce system. The challenge is that the workforce is composed by different technicians (some of them hired by collaborating companies) that own different kind of devices (tiny mobile phones, smartphones,PDAs, Blackberrys, SideKicks, etc.) made by different manufacturers. As a consequence, it is taken the decision of building an application independently of the target device, so DFAUI is used.

3 Requirements

This section defines high-level requirements for DFAUI. The categories are provided for the convenience of the reader. Although some of the requirements could be placed in multiple categories they are only listed in one.

3.1 General

1. DFAUI must be execution / runtime environment neutral (eg. operating system, Java, .NET, Ajax, C++/C).
2. DFAUI must follow the Model-View-Controller (MVC) pattern facilitating a clear separation between presentation, data and behaviour.
3. DFAUI must support client side application logic written in different programming languages.
4. DFAUI must support the relevant device independence guidelines.
5. DFAUI must support the relevant accessibility guidelines.
6. DFAUI must support internationalization and localization guidelines.
7. DFAUI must support the Architecture of the World Wide Web (AWWW) guidelines.
8. DFAUI should be able to be mixed together with other XML languages.
9. DFAUI must be modular. For example, an authoring unit may use only selected modules of DFAUI such as data binding.
10. DFAUI must be extensible allowing third parties to add new UI components and modules or modify existing UI components.
11. DFAUI must provide a mechanism to allow the reuse of part of an authring unit without copying and paste it.
12. DFAUI must allow a developer to use different expression languages.
13. DFAUI should provide mechanisms for adding metadata (documentation, author, creation date, keywords, etc) to a DFAUI authoring unit.
14. DFAUI must provide an API to modify DFAUI constructs.

3.2 User Interface Components

The following are general requirements regarding UI component sets:

1. DFAUI should provide different UI components.
2. DFAUI should provide or reuse declarative means to hide, show, enable or disable any UI component.
3. DFAUI should provide or reuse means to declare hints for UI adaptation, i.e. pagination.
4. DFAUI should provide means to declare some UI components that could be instantiated later in a document. This is something similar to the defs construction specified by SVG.
5. DFAUI should provide a repetition model for UI components.

3.2.1 List of user interface components

1. A UI component aimed to place a separation (a new line, an horizontal / vertical line, etc) between two or more UI components.
2. A UI component intended to label other UI components. A label is a textual and / or graphical description of the meaning of a UI component. A label is a means of assuring maximum accesibility.
3. A UI component that allows a user to input some piece of information that is not spread over more than one line. Typically this will be one or more words, a number, etc. The component may have an autocomplete feature.
4. A UI component that allows a user to input a date.
5. A UI component that allows a user to input a moment in time.
6. A UI component capable of outputting information to the user in different formats and styles.
7. A UI component capable of representing a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.
8. A UI component intented to the representation of the completion progress of a task.
9. A UI component that allows a user to input some piece information that can take more than one line.
10. A UI component that enables the display of rich text composed by more than one line. Rich text is a text in which one ore more words are displayed in a different font, style, color. Inside the text there could also appear hyperlinks.
11. A UI component intended to add (by reference) an external object (image, SVG, Flash, etc) to the user interface. This UI component should follow the rules of the Compound Documents by Reference Framework.
12. A UI component that allows the user to trigger an action (go to another presentation, perform a computation, etc).
13. A UI component that allows a user to select one item from a list of items.
14. A UI component that allows a user to select one or more items from a list of items.
15. A UI component capable of representing read-only data (or images) in more than one dimension (tabular format). The component should also allow the user to select one or more elements (rows / columns) of the table.
16. A UI component capable of showing some data in list format. One or more items of the list could be selected by the user.
17. A UI component that allows to input some kind of content stored in the file system of the user's computer.

1. A component aimed to a user to select a user interface "screen" to interact with from a list of user interface "screens".
2. A UI component capable of showing hierarchical tabular data that the user can collapse or expland an item when it has child items (tree). The specific requirements for this component are:
   • It should allow the programmer to define different node types.
   • It should allow the programmer to interact with the tree by means of expanding / collapsing the elements.
   • It should provide a functionality of adding or removing tree nodes.
   • It should include drag and drop features which will enable changes in the parent or position of a node.
   • It should provide the capability of adding contextual menus globally to the tree or to each one of its nodes or node types.
   • It should allow the edition of tree data using advanced mechanisms (such as combo boxes, checkboxes, etc).
3. An advanced grid component capable of showing (read-write) information in tabular format. This UI component will also including advanced mechanisms of interaction with the user such as:
   • Defining different row types (editable, not editable, lockable, scrollable, not scrollable, etc).
   • Supporting advanced tabular modes.
   • Switching the position of columns / rows of the grid.
   • Ordering the data of the grid by the different columns.
   • Adding or removing rows to the grid.
   • Adding or removing columns to the grid.
   • Adding contextual menus to each of the rows of the grid.
   • Editing some data of the grid using advanced mechanisms (such as combo boxes, buttons, checkboxes, etc).
4. A component that hosts a list of actionable items (menu).
5. A component that can contain other user interface components as well as text and image. This is visible only upon a certain event and is always layered on top of other elements.
6. A component that displays a list of choices for the user to interact with. This component is visible only upon a certain event and is always layered on top of other user interface elements. Upon the user interaction, this component becomes invisible.
7. A menu bar component used to display the different global menus that an application provides.
8. A tool bar component used to display the different actions that an application provides.
9. A status bar component used for showing the status of the application.
10. A component that allow the user to filter (by means of typing) and select between a long list of values.
11. A component capable of providing a free hand 2D graphics drawing and editing tool for the user.
12. A component that allows the user to input text as well as input the style of the text.
13. A component that conveys a message to the user. When this message is conveyed, this user is required to acknowledge it or respond to it before the user can interact with the rest of the application. This message may be for infomation purpose only, or may further require the user to take an action.

The desktop component set may include specific versions of the core component set that precludes an specific rendering. For example in the case of the "component that allow a user to select one element from a set" the desktop component set could include a combobox, radiobutton, etc, as typical renderings found in the desktop environment.

3.2.3 Extended Component Sets

The extended sets should include UI components aimed at applications in different specialized domains.

For example,a set targeted to user interfaces deployed in mobile phones may include the following UI components:

1. A UI component that allow the user to trigger a telephone call from the user interface.
2. A UI component that allow the user to add a telephone number to agenda present in the phone.
3. A UI component that allow the user to send an SMS message.

3.3 User Interface Containers

A user interface is not only composed by user interface components but also by different containers that can group together different UI components. The requirements related to containers are:

1. DFAUI must support the specification of user interfaces that include different kind of containers. At least the following:
   • A very basic container that can only contain UI components. This basic container will be very useful for small applications such as mobile applications with very simple UI requirements.
   • Different kinds of complex containers that can be nested and oriented towards complex desktop applications: At least the following:
     • A floating container that can host any other components. This floating container can be dragged or moved to different locations. Further, this container may be resized, maximized and minimized.
     • A container that can host multiple resizeable floating containers.
     • A desktop container capable of holding different windows, dialogs, status bars, tool bars, etc.
     • A container that splits a user interface into two units and the split ratio can be adjusted by the user by means o a draggable bar.
     • A tabbed container that will allow the user to switch between different subcontainers (tabs).
     • An scrollable container that will place a scroll bar when there is no enough vertical or horizontal space to show all the UI elements on the screen at the same time.
     • A container that represents a window on the screen.
     • A container that represents a dialog. A dialog is a window with the following differences:
       • By default, a dialog is not maximizable or minimizable.
       • A dialog can be modal. A modal dialog does not release the input focus while it is open.
2. DFAUI must provide the mechanims that enable the association of UI components to containers declaratively.
3. DFAUI should provide the proper mechanisms that allow to bind a layout manager to a container in a declarative manner.
4. DFAUI should provide declarative means to hide, show, enable or disable any UI container.
5. DFAUI should allow a third party to define new kinds of containers.
6. The DFAUI-DOM must provide APIs that allow a programmer to add UI elements to a container.

3.4 User Interface Interaction

The requirements specific to user interface interaction are:

1. DFAUI-API should provide all the mechanisms and functions needed to implement user interfaces based on drag and drop.

3.5 Layout Management

Layout management has to do with the situation and sizing of the different UI components grouped into containers. Layout management is influenced by two different elements: Layout managers and the UI components themselves.

Layout managers are in charge of automatically manage screen layout taking into account the layout policies and the contraints established by each UI component.

1. DFAUI should provide mechanisms for binding a layout manager to a container. This mechanisms must allow a programmer with to deal with multidevice issues, such as different layouts for different devices.
2. DFAUI should provide mechanisms for the specification of the policies (and associated parameters) of a layout manager.
3. DFAUI should provide mechanisms for the specification of the layout parameters (such as size, margins, position, etc) of each UI component.
4. DFAUI should provide at least the following kinds of layout managers:
   • A vertical layout manager which will positionate the UI components vertically.
   • An horizontal layout manager which will positionate the UI components horizontally.
   • A grid layout manager which will positionate the UI components in grid mode.
   • A card layout manager will allow you to put different components to a common container, while showing only one of them at a time. The displayed component will occupy the entire space of its parent container.
   • A border layout manager places UI omponents in up to five areas: north, south, west, east, and center. Components placed in north and south stretch horizontally. Components placed in the west and the east stretch vertically. Components placed in center stretch in both directions, so that the remaining space fills with the center component.
   • A flow layout manager lays out UI components in a single row or column depending on the position and size specified for each UI component. This manager starts a new row or column if a UI component's container isn't sufficiently wide or high.
   • A free layout manager in which UI components themselves will take care of their final position.
5. DFAUI should allow a third party to define new kinds of layout managers.

3.6 Application Logic

1. The application logic must be able to be embedded within a DFAUI document.
2. The application logic must be able to be separated from its associated DFAUI document.
3. DFAUI should allow a programmer to declare the use of pieces of application logic written in different programming languages or executed at different sides (client side, server side, etc).
4. DFAUI should provide mechanisms that allow a programmer to specify declaratively some common actions such as:
   • Showing different kind of messages (warning, error, information, etc).
   • Simple updates to the DOM tree that represents a user interface definition.
   • Simple updates to the UI components style properties.
   • Simple updates to the state UI components (disabled to enabled, readonly to read-write, etc).
   • Simple updates to the model data managed by the application.
   • Refreshment of the UI visualization.
5. DFAUI should allow a third party to define new application logic actions.

3.7 Events

1. The event names and semantics should conform to DOM event model standards.
2. The event processing model must follow existing DOM event model standards.
3. DFAUI may define new event names when there is no an appropiate DOM standard event.
4. DFAUI should allow third parties to define new events related to extented UI components.
5. There should be a way to specify event listeners declaratively.
6. There should be a way to bind event listeners with pieces of application logic that may execute at the client or at the server side.

3.8 Style Sheet

Style sheets can be used for user interface skinning, enabling developers to customize the look and feel of an application by switching a style sheet.

The requirements regarding style sheet are:

1. DFAUI must use CSS syntax and semantics for styling.
2. DFAUI should reuse existing CSS property names as long as there are similarities in semantics.
3. DFAUI should allow third parties to define new properties related to extended controls.
4. DFAUI must support a mechanism to specify the look and feel of UI components in different states (pushed, checked, etc).
5. DFAUI may support other styling mechanisms.

3.9 Data Binding

Data binding is the glue between the model and the UI components that compose the view. The requirements with respect to data binding are:

1. DFAUI must provide the necessary mechanisms to specify binding definitions. A binding definition will be composed by:
   • Type of binding: one time, one way and two way.
   • The model variable of the binding indicated using an expression language.
   • The datatype that will result from the binding.
2. DFAUI must allow a programmer to specify to which data element in the model a UI component binds to.
3. DFAUI must provide all the necessary constructs that allow a programmer to specify iterations over bindings. This is something required for the data binding of those UI components that represent collections (tables, trees, lists ...).

3.10 Validation

Validation is a functionality that a allow a programmer to specify declaratively the restrictions on the data that will be entered by the user. The specific requirements regarding validation are:

1. DFAUI must provide constructs to define unitary validators. The parameters of a unitary validator will be:
   • If the validator demands some input to be entered or not. (required or not required).
   • The target data type of the validator. At least it must be supported all the simple types defined in XML-Schema.
   • The maximum and minimum values (range) that the validator demands.
   • The mask (date mask, time mask, regular expression) that the input must conform to.
2. DFAUI must allow a programmer to define validator chains.
3. DFAUI must include constructs to define cross validators.
4. DFAUI must allow a programmer to define new kinds of validators, extending the language.
5. DFAUI must allow a programmer to define validators (unitary and cross) based on functions written in any programming language.
6. DFAUI must allow a programmer to define validations. A validation will comprise:
   • A validator to be applied.
   • The UI component to which the validation applies.
   • The event (if any) that will trigger the validation.
7. DFAUI must provide mechanisms that allow a programmer to invoke a validator from an event handler.

3.11 Formatting

Formatting is a functionality that a allow a programmer to specify declaratively the formats of the data that will be showed in the user interface.The requirements behind this functionality will be:

1. DFAUI should allow a programmer to specify formats. A format will be based on a string mask that will serve as a template onhow information will be presented.
2. DFAUI should allow a programmer to specify formatters that will be based on a format and bound to a UI component. A formatter could also be triggered by an specific event raised by the visual control in question.
3. DFAUI should provide the syntax needed to declare formatter chains.
4. DFAUI should enable the specification of additional formatters as extensions to the language.
5. DFAUI should provide mechanisms that allow a programmer to define formatters based on code written in any programming language.

3.12 Data sources

Data sources are a delcarative way of loading different data that could come from a URL, a file, a database etc. The data could be in different formats. This data will be loaded automatically by the DFAUI agent an as a result it will be available in the application model. The requirements for this functionality are:

1. DFAUI should provide constructs intended to the declaration of datasources to be used in an authoring unit.
2. DFAUI should provide at least the following kind of data sources:
   • A datasource that gets data from a URL (including a file) in XML format.
   • A datasource that gets data from a URL (including a file) in JSON (Javascript format).
3. DFAUI must allow a developer to use different data representation mechanisms such as XML, conventional data structures written in any programming language, etc.

3.13 Model API

1. DFAUI-API should provide functions to retrieve any model element stored in the data context at different scopes.
2. DFAUI-API should provide functions to evaluate any expression (whose syntax conforms to an expression language used) against the the data context.
3. DFAUI-API should provide functions to add a new model element to the data context at different scopes.

A References

[1]

Rich Internet Applications Are the Next Evolution of the Web, Mark Driver, Ray Valdes, Gene Phifer, Garnter, May 2005

[2]

Rich Internet Applications: Market Trends and Technologies , Ron Schmelzer, Zapthink, July 2006

[3]

Rich Internet Applications Based on Ajax, Flash, and Java Will Quickly Supplant Current Static Web Applications and Portals; Users Demanding Rich Capabilities for Interaction and Integration Promised by Web 2.0 , Ron Schmelzer, Zapthink, July 2006

[4]

XML Markup Languages for User Interface Definition ,

B Acknowledgements

The editors acknowledge the following contributors:

Juan J. Hierro, Telefónica Investigación y Desarrollo S.A.U.

The WAF Working Group also acknowledges the Editors of the following documents: