W3C W3C Member Submission

Advanced Service Front-End Description Language (ASFE-DL)

W3C Working Group Submission 1 February 2012

Editors:
Jean Vanderdonckt, UCL
Vivian Motti, UCL
Fabio Paternò, ISTI-CNR
Carmen Santoro, ISTI-CNR
Lucio Davide Spano, ISTI-CNR

This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.


Abstract

This is a submission to the W3C Model-Based UI Working Group and describes a metamodel and XML format for interchange of user interface designs between different design tools.

Table of Contents

1. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119].

2. Introduction

This section is non-normative.

This document defines a metamodel and XML format for the Advanced Service Front-End Description Language (ASFE-DL), which is intended as a basis for interchange of user interface designs at the level of the abstract user interface. This expresses the user interface design independent of the user agent device capabilities, and the modality of interaction. It corresponds to the Platform-Independent-Model – PIM in Model Driven Engineering (MDE). Standardization of this work will depend on being able to demonstrate the interoperable interchange of user interface designs between multiple independent UI design tools.

3. ASFE-DL Metamodel

This section is normative.

In this section, we describe the first version of the Advanced Service Front-End Description Language (ASFE-DL). This language will enable the development and authoring of service front ends in accordance with the Cameleon Reference Model described in [CAMELEON] and depicted in the following diagram.

Figure 1: CAMELEON Reference Framework

In this first version, we focused on the creation of an AUI meta-model, starting from the CNR and UCL experience respectively in MARIA [Paternò2009] and UsiXML [UsiXML]. The idea is to create a unified and more complete language, combining the strengths of the two languages, unifying concepts and adding new features that will allow this language to meet requirements for context aware adaptation of service front ends.

In order to achieve this goal, we analysed the metamodels of both languages. Afterwards, we have identified an initial set of concepts than can represent a first basis for ASFE-DL to be further refined through discussions in the W3C Model-Based UI Working Group. By analyzing the AUI metamodels of MARIA and UsiXML, a number of situations were handled in order to come up with a preliminary shared proposal for the ASFE-DL.

In some cases, there were concepts directly corresponding to each other between metamodels (apart from slightly different names used in the two originated languages). For instance, the original UsiXML elements of types AbstractOrdering, AbstractHierarchy and AbstractRepetition (corresponding to for MARIA’s Ordering, Hierarchy, and Repeater entities) have been basically kept in the this proposal respectively as Ordering, Hierarchy, and Repetition. The same occurred for the UsiXML AbstractRelationship concept, which was easily identified as modelling the same concept as Interactor_composition existing in MARIA language (eventually, we decided to keep the UsiXML naming and to then have the AbstractRelationship element in the ASFE-DL language). Furthermore, both languages support a clear separation of concerns between the UI specification and the description of data handled in it, by including a specific element for handling data: this was called DomainModel in UsiXML and DataModel in Maria (the latter name was eventually selected for the ASFE-DL). However, in other situations, the correspondence between both languages/models was not so direct. For instance, this is the case when the same concept is modelled in a slightly different way, as for the event objects. Indeed, in UsiXML the different types of events are not connected to specific types of interactors, while in MARIA this is the case. Therefore, in the ASFE-DL, we preferred to keep the MARIA approach as it enables a more controlled handling of the specific events associated to each particular type of abstract interactor.

Finally, there were concepts appearing in just one metamodel, which we judged useful to bring in the ASFE-DL. For instance, it was the case of the Connection elements (existing in MARIA language), which allow specifying how it is possible to move from one abstract interaction unit to another one.

Figure 2: ASFE-DL AUI metamodel (UML View)

Figure 2 shows the UML class diagram [UML] for this preliminary version of the ASFE-DL at the abstract level. We used different colours in order to highlight different parts of the metamodel: sky-blue for the main structure of the interface, green for the interactor hierarchy, red for the classes that model the relationships between interactors and yellow for the classes that model the UI behaviour.

The class that represents an abstract user interface model is called AbstractUIModel. It contains the entire specification of both the UI structure and behaviour. The interface contains an optional DataModel, which defines the set of objects and variables. The data model contains all the data types that are manipulated by the UI in order to allow interaction with the user. The composition relation between the DataItem and the DataModel class represents such collection of data types. A DataItem indeed represents a single data type element.

An AbstractUIModel consists of a composition of AbstractInteractionUnits. Each instance of this class represents a part of an application user interface that should be presented to the user at once. Each AbstractInteractionUnit has two attributes: a unique identifier (id attribute) and a name (which is the name of the abstract interaction unit).

An AbstractInteractionUnit is composed of AbstractInteractors and AbstractRelationships. The first one among these AbstractInteractionUnits will be the starting point for interaction.

It is possible to model the navigation among the different abstract interaction units defining instances of the Connection class. A connection (which has a unique identifier, id attribute) specifies the target abstract interaction unit and the interactor (or interactors) that triggers such navigation. It is also possible for the connection to specifiy more than one target interaction unit. In this case, the specification will contain also the condition (see the related attribute in the specification of the Connection element) for the dynamic selection of the target among the specified set of abstract interaction units.

The abstract class AbstractInteractor defines a generic interactor, which represents a generic user interface object. Its subclasses create a partition, which defines a set of different categories according to the interaction semantics. These categories are:

Each AbstractInteractor can be optionally connected to a DataItem, specifying that it represents the referenced data item in the user interface. Each AbstractInteractor has also a number of attributes:

An AbstractRelationship element has a number of attributes:

The AbstractDialogModel class defines the behaviour of the UI. It contains a composition of a set of AbstractEventCompositions, which consist of Events, connected using CompositionOperators. Each CompositionOperator has an identifier, determining the type of composition that can occur on sets of events. Such compositions define the set of events observed by the UI in a given state. Example of event compositions can be e.g. concurrency, sequential enabling, etc. Event is the abstract class that models all abstract asynchronous notifications about the changes on the state of the interactors or user inputs.

To each generic Event, it is possible to associate a list of EventHandlers, which specifies all the actions that have to be performed as a reaction to a certain event. Each EventHandler has its own name, and can be also guarded by a condition, which defines constraints for the reactions. The generic event class is refined into SelectionEvent, EditEvent and ControlEvent classes:

4. ASFE-DL XML Schema

This section is normative.

This section defines an XML schema [XSD1, XSD2] for ASFE-DL as a basis for an XML serialization of ASFE-DL models

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">
    <!-- the root element of the ASFE-DL schema -->
    <xs:element name="abstractUIModel" type="AbstractUIModelType" />
    
    <!-- 
        ******************** GENERAL STRUCTURE *******************
    -->
    
    <!-- Abstract UI Model -->
    <xs:complexType name="AbstractUIModelType">
        <xs:sequence>
            <xs:element name="abstractDialogModel"
              type="AbstractEventCompositionType"/>
            <xs:element name="abstractInteractionUnit"
              type="AbstractInteractionUnitType"/>
        </xs:sequence>
    </xs:complexType>
    
    <!-- Abstract Interaction Unit -->
    <xs:complexType name="AbstractInteractionUnitType">
        <xs:sequence>
            <xs:element name="dataModel" type="DataModelType"/>
            <xs:element name="connections" type="ConnectionsType" />
            <xs:choice minOccurs="1" maxOccurs="1">
                <xs:group ref="AbstractRelationshipGroup"/>
                <xs:group ref="AbstractInteractorGroup"/>
            </xs:choice>
        </xs:sequence>
    </xs:complexType>
    
    <xs:complexType name="ConnectionsType">
        <xs:choice minOccurs="0" maxOccurs="unbounded">
            <xs:element name="connection" type="ConnectionType"/>
        </xs:choice>
    </xs:complexType>
    
    <!-- Connection -->
    <xs:complexType name="ConnectionType">
        <xs:attribute name="id" type="xs:ID"/>
        <xs:attribute name="interactorId" type="xs:IDREF"/>
        <xs:attribute name="condition" type="xs:string"/>
    </xs:complexType>
    
    <!-- 
        ******************** DATA MODEL *******************
    -->
    
    <!-- Data Model -->
    <xs:complexType name="DataModelType">
        <xs:sequence>
            <xs:element name="dataItem"
              type="DataItemType"
              maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>
    
    <!-- Data Item -->
    <xs:complexType name="DataItemType">
        <xs:attribute name="id" type="xs:ID"/>
    </xs:complexType>
    
    <!-- 
        ******************** ASTRACT RELATIONSHIP *******************
    -->
    
    <!-- Abstract Relationship -->
    <xs:attributeGroup name="abstractRelationshipAttributes">
        <xs:attribute name="id" type="xs:ID"/>
        <xs:attribute name="hidden" type="xs:boolean"/>
    </xs:attributeGroup>
    
    <xs:group name="AbstractRelationshipGroup">
        <xs:choice>
            <xs:element name="repetition" type="RepetitionType"/>
            <xs:element name="hierarchy" type="HierarchyType" />
            <xs:element name="grouping" type="GroupingType"/>
            <xs:element name="ordering" type="OrderingType"/>
            <xs:element name="dependency" type="DependencyType"/>
        </xs:choice>
    </xs:group>
    
    <!-- Repetition -->
    <xs:complexType name="RepetitionType">
        <xs:choice minOccurs="1" maxOccurs="unbounded">
            <xs:group ref="AbstractRelationshipGroup"/>
            <xs:group ref="AbstractInteractorGroup"/>
        </xs:choice>
        <xs:attributeGroup ref="abstractRelationshipAttributes"/>
    </xs:complexType>
    
    <!-- Hierarchy -->
    <xs:complexType name="HierarchyType">
        <xs:choice minOccurs="1" maxOccurs="unbounded">
            <xs:group ref="AbstractRelationshipGroup"/>
            <xs:group ref="AbstractInteractorGroup"/>
        </xs:choice>
        <xs:attributeGroup ref="abstractRelationshipAttributes"/>
        <xs:attribute name="hierarchyValue" type="xs:int" />
    </xs:complexType>
    
    <!-- Grouping -->
    <xs:complexType name="GroupingType">
        <xs:choice minOccurs="1" maxOccurs="unbounded">
            <xs:group ref="AbstractRelationshipGroup"/>
            <xs:group ref="AbstractInteractorGroup"/>
        </xs:choice>
        <xs:attributeGroup ref="abstractRelationshipAttributes"/>
    </xs:complexType>
    
    <!-- Ordering -->
    <xs:complexType name="OrderingType">
        <xs:choice minOccurs="1" maxOccurs="unbounded">
            <xs:group ref="AbstractRelationshipGroup"/>
            <xs:group ref="AbstractInteractorGroup"/>
        </xs:choice>
        <xs:attributeGroup ref="abstractRelationshipAttributes"/>
        <xs:attribute name="orderingValue" type="xs:int" />
    </xs:complexType>
    
    <!-- Dependency -->
    <xs:complexType name="DependencyType">
        <xs:choice minOccurs="1" maxOccurs="unbounded">
            <xs:group ref="AbstractRelationshipGroup"/>
            <xs:group ref="AbstractInteractorGroup"/>
        </xs:choice>
        <xs:attributeGroup ref="abstractRelationshipAttributes"/>
    </xs:complexType>
    
    <!-- 
        ******************** ABSTRACT INTERACTOR  *******************
    -->
    
    <!-- Abstract Interactor -->
    <xs:attributeGroup name="abstractInteractorAttributes">
        <xs:attribute name="id" type="xs:ID" use="required"/>
        <xs:attribute name="enabled" type="xs:boolean" default="true" />
        <xs:attribute name="focus" type="xs:boolean" default="false" />
        <xs:attribute name="hidden" type="xs:boolean" default="false" />
        <xs:attribute name="continuous_update"
          type="xs:boolean" default="false"/>
        <xs:attribute name="dataReference" type="xs:IDREF" />
    </xs:attributeGroup>
    
    
    <xs:group name="AbstractInteractorGroup">
        <xs:choice>
            <xs:group ref="ControlGroup"/>
            <xs:element name="edit" type="EditType" />
            <xs:element name="onlyOutput" type="OnlyOutput"/>
            <xs:group ref="SelectionGroup"/>
        </xs:choice>
    </xs:group>
    
    <!-- Control -->
    <xs:group name="ControlGroup">
        <xs:choice>
            <xs:element name="activator" type="ActivatorType"/>
            <xs:element name="navigator" type="NavigatorType"/>
        </xs:choice>
    </xs:group>
    
    <!-- Activator -->
    <xs:complexType name="ActivatorType">
        <xs:sequence>
            <xs:group ref="ControlEventGroup"/>
        </xs:sequence>
        <xs:attributeGroup ref="abstractInteractorAttributes"/>
    </xs:complexType>
    
    <!-- Navigator -->
    <xs:complexType name="NavigatorType">
        <xs:sequence>
            <xs:group ref="ControlEventGroup"/>
        </xs:sequence>
        <xs:attributeGroup ref="abstractInteractorAttributes"/>
    </xs:complexType>
    
    <!-- Only Output -->
    <xs:complexType name="OnlyOutput">
        <xs:attributeGroup ref="abstractInteractorAttributes"/>
    </xs:complexType>
    
    <!-- Edit -->
    <xs:complexType name="EditType">
        <xs:sequence>
            <xs:group ref="EditEventGroup"/>
        </xs:sequence>
        <xs:attributeGroup ref="abstractInteractorAttributes"/>
        <xs:attribute name="value" type="xs:string"/>
    </xs:complexType>
    
    <!-- Selection -->
    
    <xs:group name="SelectionGroup">
        <xs:choice>
            <xs:element name="singleChoice" type="SingleChoiceType"/>
            <xs:element name="multipleChoice" type="MultipleChoiceType" />
        </xs:choice>
    </xs:group>
    
    <xs:attributeGroup name="selectionAttributes">
        <xs:attribute name="cardinality" type="xs:int" />
    </xs:attributeGroup>
    
    <!-- Single choice -->
    <xs:complexType name="SingleChoiceType">
        <xs:sequence>
            <xs:element name="choiceElement" type="choiceElementType"
              minOccurs="0" maxOccurs="unbounded"/>
            <xs:group ref="SelectionEventGroup"/>
        </xs:sequence>
        <xs:attributeGroup ref="abstractInteractorAttributes"/>
        <xs:attributeGroup ref="selectionAttributes"/>
        <xs:attribute name="selected" type="xs:string" />
    </xs:complexType>
    
    <!-- Multiple choice -->
    <xs:complexType name="MultipleChoiceType">
        <xs:sequence>
            <xs:element name="choiceElement" type="choiceElementType"
              minOccurs="0" maxOccurs="unbounded"/>
            <xs:element name="selected" type="xs:string"
              minOccurs="0" maxOccurs="unbounded" />
            <xs:group ref="SelectionEventGroup"/>
        </xs:sequence>
        <xs:attributeGroup ref="abstractInteractorAttributes"/>
        <xs:attributeGroup ref="selectionAttributes"/>
    </xs:complexType>
    
    <xs:complexType name="choiceElementType">
       <xs:attribute name="value" type="xs:string" use="required"/>
    </xs:complexType>
    
    <!-- 
        ******************** BEHAVIOUR *******************
    -->
    
    <!-- Abstract Event Composition -->
    <xs:complexType name="AbstractEventCompositionType">
        <xs:choice minOccurs="1" maxOccurs="unbounded">
            <xs:element name="eventReference" type="EventReferenceType"/>
            <xs:element name="abstractEventComposition"
              type="AbstractEventCompositionType"/>
        </xs:choice>
        <xs:attribute name="compositionOperator" type="CompositionOperatorType"/>
    </xs:complexType>
    
    <!-- 
        composition operator
    -->
    <xs:simpleType name="CompositionOperatorType">
        <xs:restriction base="xs:string">
            <xs:enumeration id="SequentialEnabling" value="SequentialEnabling" />
            <xs:enumeration id="Choice" value="Choice" />
            <xs:enumeration id="Interleaving" value="Interleaving" />
            <xs:enumeration id="Synchronization" value="Synchronization" />
            <xs:enumeration id="SequentialEnablingInfo"
              value="SequentialEnablingInfo" />
            <xs:enumeration id="Disabling" value="Disabling" />
            <xs:enumeration id="SuspendResume" value="SuspendResume" />
            <xs:enumeration id="OrderIndependence" value="OrderIndependence" />
        </xs:restriction>
    </xs:simpleType>
    
    <!-- Selection Events -->
    <xs:group  name="SelectionEventGroup" >
        <xs:sequence>
            <xs:element name="events">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="selectionChanged" type="EventType"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:group>
    
    <!-- Edit Events -->
    <xs:group  name="EditEventGroup" >
        <xs:sequence>
            <xs:element name="events">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="valueChanged" type="EventType"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:group>
    
    <!-- Control Events -->
    <xs:group  name="ControlEventGroup" >
        <xs:sequence>
            <xs:element name="events">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="activation" type="EventType"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:group>
    
    <!-- Event -->
    <xs:complexType name="EventType">
        <xs:sequence>
            <xs:element name="eventHandler" type="EventHandlerType"
              minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute type="xs:string" name="name"/>
    </xs:complexType>
    
    <!-- Event Handler -->
    <xs:complexType name="EventHandlerType">
        <xs:attribute type="xs:string" name="name"/>
        <xs:attribute type="xs:string" name="condition"/>
    </xs:complexType>
    
    <!-- Event Reference -->
    <xs:complexType name="EventReferenceType">
        <xs:attribute name="interactorId" type="xs:IDREF"/>
        <xs:attribute name="eventName" type="xs:string" />
    </xs:complexType>
    
</xs:schema>

A. References

A.1 Normative references

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[UML]
Unified Modeling Language (UML) version 1.4.2. January 2005. ISO/IEC 19501. URL: http://www.omg.org/spec/UML/ISO/19501/PDF/
[XSD1]
H. Thompson, D. Beech, M. Maloney, & N. Mendelsohn. XML Schema Part 1: Structures Second Edition. October 2004. W3C Recommendation. URL: http://www.w3.org/TR/xmlschema-1/
[XSD2]
P. Biron, & A. Malhotra. XML Schema Part 2: Datatypes Second Edition. October 2004. W3C Recommendation. URL: http://www.w3.org/TR/xmlschema-2/

A.2 Informative references

[ABNF]
D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet RFC 5234. URL: http://www.ietf.org/rfc/rfc5234.txt
[CAMELEON]
CAMELEON (Context Aware Modelling for Enabling and Leveraging Effective interactiON) Project (FP5-IST4-2000-30104), http://giove.isti.cnr.it/projects/cameleon.html.
[Paternò2009]
F. Paternò, C. Santoro, L.D. Spano, "MARIA: A Universal Language for Service-Oriented Applications in Ubiquitous Environment", ACM Transactions on Computer-Human Interaction, Vol.16, N.4, November 2009, pp.19:1-19:30, ACM Press.
[UsiXML]
UsiXML website: www.usixml.org [Vanderdonckt2004] Vanderdonckt, J., Limbourg, Q., Michotte, B., Bouillon, L., Trevisan, D., Florins, M., UsiXML: a User Interface Description Language for Specifying Multimodal User Interfaces, in Proc. of W3C Workshop on Multimodal Interaction WMI'2004 (Sophia Antipolis, 19-20 July 2004).