IEC PAS 62883:2014

IEC PAS 62883 ®
Edition 1.0 2014-03
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
colour
inside
The universAAL framework for user interaction in multimedia AAL spaces
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 14
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 55 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
IEC PAS 62883 ®
Edition 1.0 2014-03
PUBLICLY AVAILABLE
SPECIFICATION
PRE-STANDARD
colour
inside
The universAAL framework for user interaction in multimedia AAL spaces

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
V
ICS 13.180; 33.160 ISBN 978-2-8322-1452-7

– 2 – IEC PAS 62883:2014  IEC 2014
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 8
2 Normative references . 9
3 Terms, definitions and abbreviations . 9
3.1 Terms and definitions . 9
3.2 Abbreviation . 12
4 The Specification of the universAAL UI Framework . 12
4.1 Overview. 12
4.2 Analysis of the relationships between UI Handlers and I/O Channels . 13
4.3 Dialog descriptions . 15
4.4 The Adaptation Concept. 18
4.4.1 Overview . 18
4.4.2 Responsibilities of Applications . 18
4.4.3 Responsibilities of UI handlers . 19
4.4.4 Responsibilities on the brokerage layer . 20
4.5 Provisions of the UI Framework . 22
4.5.1 Introduction . 22
4.5.2 The UI Bus and its brokerage protocols . 22
4.5.3 The dialog manager and its role in assisting the UI Bus . 28
4.5.4 The Resource Manager . 30
Annex A (informative) Use cases . 31
A.1 Use Case: Supporting rich human computer interaction . 31
A.2 Use Case: Healthy Lifestyle Service Package Use Case (universAAL) . 32
Annex B (informative) An Overview of the universAAL Project . 33
Bibliography . 35

Figure 1 – Paradigm shift from HCI to HEI . 6
Figure 2 – logical separation of application and presentation layers . 7
Figure 3 – The scope of the specified UI framework marked by the green colour . 8
Figure 4 – The notion of AAL spaces . 9
Figure 5 – The need of smart environments to utilize channels for bridging between the
physical world and the virtual realm . 10
Figure 7 – The notion of a smart environment . 11
Figure 8 – An open system for plugging in applications and UI handlers independently
from each other . 13
Figure 9 – Channel binding by I/O devices . 13
Figure 10 – The notion of a driver with the case of a UPNP-aware driver . 14
Figure 11 – The case of a universAAL aware driver . 14
Figure 12 – Possible relationship between UI handlers and drivers . 15
Figure 13 – The dialog package based on the notion of a form . 16
Figure 14 – A possible graphical visualization of the mapping between dialog types
and the predefined standard groups . 17
Figure 15 – The universAAL framework for supporting adaptivity, which builds on top of
the universAAL context and service buses (see footnote 4) . 18

Figure 16 – A model for describing access impairments . 20
Figure 17 – Summary of the adaptation parameters . 21
Figure 18 – The components comprising the universAAL UI framework . 22
Figure 19 – The main messages exchanged on the UI Bus . 23
Figure 20 – The notion of a UI request as constructed by applications . 23
Figure 21 – Overview of the sequence of actions when the priority check is positive . 24
Figure 22 – The case of switching to a new UI handler when handling changes in the
context . 25
Figure 24 – The abstract class to be extended by applications that want to send UI
requests to the UI bus . 28
Figure 25 – The abstract class to be extended by UI handlers that accept UI requests
forwarded by the UI bus for rendering . 28
Figure 26 – The interface of the UI Bus . 28
Figure 27 – Access to the resources managed by the RM . 30
Figure B.1 – Project ID Card . 33
Figure B.2 – The three pillars of the universAAL platform . 34

– 4 – IEC PAS 62883:2014  IEC 2014
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
THE UNIVERSAAL FRAMEWORK FOR USER
INTERACTION IN MULTIMEDIA AAL SPACES

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
A PAS is a technical specification not fulfilling the requirements for a standard, but made
available to the public.
IEC-PAS 62883 has been processed by IEC technical committee 100: Audio, video and
multimedia systems and equipment.

The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document
Draft PAS Report on voting
100/2189/PAS 100/2228/RVD
Following publication of this PAS, which is a pre-standard publication, the technical committee
or subcommittee concerned may transform it into an International Standard.

This PAS shall remain valid for an initial maximum period of 3 years starting from the
publication date. The validity may be extended for a single period up to a maximum of 3 years,
at the end of which it shall be published as another type of normative document, or shall be
withdrawn.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
– 6 – IEC PAS 62883:2014  IEC 2014
INTRODUCTION
Ambient Assisted Living (AAL) strives to ensure the independence, safety, wellbeing and
autonomy of users by using ICT, including multimedia systems and equipment and audio /
video communication, for creating intelligent living environments that react to the needs of
users by providing relevant assistance. Such intelligent environments can be labelled as AAL
Spaces, which are characterized by a number of devices that can be stationary, mobile or
embedded within other objects. Multiple users can find themselves in an AAL space
simultaneously, possibly moving around within the AAL space, and entering and leaving it
dynamically. These characteristics introduce new challenges when it comes to handling
interaction with users in AAL spaces.
With the assumption that people are surrounded by highly distributed systems of networked
interactive devices, AAL intensifies the paradigm shift from Human-Computer Interaction (HCI)
to Human-Environment Interaction (HEI). One of the main challenges of HEI is to keep the
multiplicity of functional units hidden to humans while making the functionality provided by
them easily available based on natural ways of interaction. Instead of controlling each device
separately, users should be able to interact with a whole device ensemble as one single unit
and articulate goals instead of looking for functionality at the level of each single device
separately (Figure 1).
Figure 1 – Paradigm shift from HCI to HEI
Another important challenge for designers and developers of systems in AAL spaces is that
interaction with applications can take place through a variety of devices at different locations
with different capabilities in terms of serving a single user privately or not, supported
modalities, modality-specific parameters such as screen size and resolution, power
consumption, etc., which implies the need in AAL spaces to logically separate the application
layer from the presentation layer (Figure 2).
Consequently, applications have to use abstract user interfaces that are device-, modality-,
and layout-neutral and allow to postpone the rendering of the user interface to the execution-
time, which makes it possible to interact with users in a personalized and situation-aware way.
The separation of concerns also facilitates the creation of clean programming interfaces
based on an open and flexible architecture that have to enable the plug-and-play of both
applications and user interaction handlers (UI handlers), and allows UI handlers to serve
arbitrary applications.
The resulted openness complements the openness supported by IEC 62481-2 that enables
the sharing of multimedia content and streams within an ensemble of devices. It adds the

perspective of sharing the input and output channels provided by those devices to the DLNA
perspective of content sharing.

Figure 2 – logical separation of application and presentation layers

_____________
This understanding of the term I/O channel is based on the actual roles of devices that enable interaction with
human users: a display provides a visual output channel, a loudspeaker, an audio output channel, and a
microphone, an audio input channel.

– 8 – IEC PAS 62883:2014  IEC 2014
THE UNIVERSAAL FRAMEWORK FOR USER
INTERACTION IN MULTIMEDIA AAL SPACES

1 Scope
This Publicly Available Specification (PAS) specifies a framework for adaptive handling of
explicit interaction among humans and AAL spaces. This is based on a differentiation
between explicit and implicit interaction as a consequence of the paradigm shift from Human-
Computer Interaction to Human-Environment Interaction, further explained in the definition of
the latter term.
As a framework, a main subject matter of the specification is the identification of relevant
areas for further standardization, thereby also looking at the interrelationships among the
identified areas. The PAS also provides a first extensible specification in some of those areas.
The proposed UI framework has been derived from the logical separation of application and
presentation layers as depicted by Figure 2, and encompasses the following elements
(Figure 3):
• Analysis of the relationships between UI handlers and I/O devices without specifying
possible languages, models, or abstract APIs for interaction with these devices, as there
are certain international standardization activities that go in this direction ;
• the language and model for describing application-specific dialogs / user interfaces as part
of UI requests made by applications to the UI framework;
• the adaptation concept and parameters needed to achieve adaptive UI and the way they
affect UI requests; and
• Protocols used by the UI framework to broker between UI handlers and applications as
pluggable components.
I/O Device
not covered
UI Handler
UI Request
(forwarded)
UI Response
Brokerage
UI Request
UI Response
(forwarded)
Application
Figure 3 – The scope of the specified UI framework marked by the green colour
_____________
For example [3] on representing user input coming from input devices.

2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 62481-2, Digital living network alliance (DLNA) home networked device interoperability
guidelines – Part 2: DLNA media formats
ISO/IEC Guide 71:2001, Guidelines for standards developers to address the needs of older
persons and persons with disabilities
ISO 9241-11:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 11: Guidance on usability
ISO 9241-110:2006, Ergonomics of human-system interaction - Part 110: Dialogue principles
3 Terms, definitions and abbreviations
For the purposes of this document, the following terms and definitions apply.
3.1 Terms and definitions
3.1.1
ambient assisted living
AAL
products, services, environments and facilities used to support those whose independence,
safety, wellbeing and autonomy are compromised by their physical or mental status
Note 1 to entry: In this PAS, AAL refers to the usage of ICT, including multimedia systems and equipment and
audio / video communication, for creating intelligent living environments that react to the needs of users by
providing relevant assistance.
[SOURCE: ISO/IEC GUIDE 71:2001]
3.1.2
AAL service user
person who interacts with an AAL system or is connected with an AAL system
3.1.3
AAL space
denotes a smart environment that provides AAL services to its users

Figure 4 – The notion of AAL spaces

– 10 – IEC PAS 62883:2014  IEC 2014
3.1.4
channel
denotes the bridging passage that smart environments need between the physical world and
the virtual realm (Figure 5). Channels are realized by devices. Depending on the kind of
channel opened, a channel might be called a sensing channel (realized by sensors), an acting
channel (realized by actuators), an input channel (realized by microphones, keyboards, etc.),
or an output channel (realized by displays, loudspeakers, etc.). The latter two types of
channels might be referred to as I/O channels

Figure 5 – The need of smart environments to utilize channels
for bridging between the physical world and the virtual realm
3.1.5
human-environment interaction
interaction in smart environments is generally divided into two major areas: implicit and
explicit interaction
Implicit interaction is mostly about using sensing channels for observation of happenings, with
or without involvement of humans, in order to recognize in the background relevant situations
to which the environment might be able to react in a desired way.
Explicit interaction, on the contrary, is about situations in which a human user seeks the
dialog with the environment or vice versa, for instance when the user instructs that the
brightness of the TV should be increased or when the environment notifies the user that it is
time to take a certain medicine. Explicit interaction takes place by utilizing input and output
channels provided by I/O devices.
3.1.6
I/O device
an abbreviation for input and / or output device. A device that provides an input and / or
output channel for facilitating explicit interaction between a smart environment and its human
users. Input devices, such as a microphone, a keyboard, or a mouse, can capture an
instruction or response that is provided by a human user and represent it in terms of data in
the virtual realm (Figure 6). Upon receive of data within the virtual realm that is intended to be
presented to human users, output devices, such as displays and loudspeakers, can make it
perceivable to the addressed humans

Figure 6 – The role of devices in realizing bridging channels
3.1.7
multimodal UI handler
denotes UI handlers that perform the interaction by using multiple channels in parallel,
possibly with a hybrid mix supporting different modalities
3.1.8
smart environment
denotes an environment centred on its human users in which a set of embedded networked
artefacts, both hardware (HW) and software (SW), collectively realize the paradigm of
Ambient Intelligence, mainly by providing for context-awareness and personalization, adaptive
reactivity, and anticipatory pro-activity

Figure 7 – The notion of a smart environment
3.1.9
user
person who interacts with the product, service or environment
3.1.10
user interface
all components of an interactive system (software or hardware) that provide information
and/or control functions for the user to accomplish specific tasks with the interactive system

– 12 – IEC PAS 62883:2014  IEC 2014
3.2 Abbreviation
AAL Ambient Assisted Living
API Application programming interface
Cf confer
DLNA Digital Living Network Alliance
e.g. for example
etc. et cetera
GUI Graphical user interface
HCI Human-Computer Interaction
HEI Human-Environment Interaction
HTML Hypertext Markup Language
HW Hardware
ICT Information and communications' technology
i.e. id est, that is to say
I/O channels Input/Output channel
OWL Web Ontology Language
RDF Resource Description Framework
RM Resource Manager
SW Software
UI User Interaction
UI model User Interaction model
UIML User Interface Markup Language
uAAL universAAL
UPNP Universal Plug and Play
W3C World Wide Web Consortium
XForms W3C Standard at http://www.w3.org/TR/xforms/
XML Extensible Markup Language
XPath XML Path Language; W3C Standard at http://www.w3.org/TR/xpath/
4 The Specification of the universAAL UI Framework
4.1 Overview
As depicted in the Introduction to this PAS, the universAAL UI Framework for Multimedia AAL
spaces is based on separating the application layer from the presentation layer by introducing
(1) a new type of software components called UI handlers and (2) a brokerage mechanism
between the application and presentation layers. The goal is to achieve an open system in
which arbitrary applications as well as UI handlers can be plugged in independently from each
other while enabling applications to benefit from support for multimodal interaction both by the
framework itself and by the UI handlers:

Figure 8 – An open system for plugging in applications
and UI handlers independently from each other
4.2 Analysis of the relationships between UI Handlers and I/O Channels
UI handlers are seen responsible for handling requests for interacting with human users. To
do so, they need to utilize the available I/O channels but are not necessarily supposed to take
over the binding and management of those channels. On the other side, the "manager" of a
single input or output channel is usually not able to handle the whole of a UI request sent by
an application because applications often wait for user response in the context of some
information to be presented to the user; as a result. At least one output channel and one input
channel are supposed to be utilized simultaneously by the same UI handler in order to be able
to interpret user input in the context of the output presented to the user.
Therefore, it is important to have a more precise look at the relationship between UI handlers
and I/O channels: Section 3.1 states that channels are realized by certain devices but it does
not say anything about their binding and availability in the virtual realm. In the concept map in
Figure 9, those definitions are extended by introducing the concept of Channel Binding; the
same concept can be used for both input and output channels:

Figure 9 – Channel binding by I/O devices
The device that realizes a channel has to have an integrated solution for providing access to
the channel. This might be very low-level, at hard- and firmware level to exchange certain bits
and bytes through a physical connector interface (called Embedded Binding) or already
software using higher-level protocols and abstractions (called Driver). Drivers might be
provided by third-party and / or run on third-party devices. Like Figure 10 denotes, a driver
might wrap another driver in order to comply with higher-level abstractions (e.g. a “UPNP
driver”) for binding a special-purpose device that is not readily “UPNP-aware” usually uses

– 14 – IEC PAS 62883:2014  IEC 2014
“Embedded Bindings” or “Legacy Drivers” for providing wrappers that interact at the UPNP
level of abstraction.
In particular, the higher-level abstractions might only make sense in the context of a
framework created for certain purposes (cf. a windowing system that uses a mouse driver and
already interprets the mouse events in the context of the bunch of objects in the framework).

Figure 10 – The notion of a driver with the case of a UPNP-aware driver
Similar to the UPNP-aware driver, a universAAL-aware driver should use the API of the
universAAL middleware in order to provide related data and functionality in the universAAL
realm (Figure 11):
Figure 11 – The case of a universAAL aware driver
Like Figure 12 denotes, the development of a UI handler can be based on any of the available
alternatives.
_____________
A driver that is UPNP-aware, provides data to the UPNP realm by using the UPNP eventing mechanisms and it
renders services in the UPNP realm by using the UPNP control mechanisms.
The universAAL middleware provides for sharing data and functionality using the abstraction of virtual
communication buses that broker messages between attached components; there are three buses, each
responsible for a specific class of brokerage cases: the context bus works on a publish-subscribe base and is
responsible for the brokerage of events, the service bus works on a request-response base and brokers
services, and finally the UI bus (subject to discussion in Section 4.5.2) that brokers requests for interaction with
human users to UI handlers. The three buses of the universAAL middleware are quite in analogy to the building
blocks “Eventing”, “Control” and “Presentation” in the common architecture of UPNP. To publish events on the
context bus, a component has to extend an interface called “Context Publisher”, and to provide services on the
service bus, it has to extend “Service Callee”.

Figure 12 – Possible relationship between UI handlers and drivers
An input or output channel can be associated with a certain location (the location of the
device that realizes the channel), a modality, and a privacy level . These are important
characteristics when it comes to context-aware and personalized selection of an appropriate
UI handler, which is supposed to be a crucial task of the UI framework.
There is an analogy between UI handlers and Web browsers ([4]). The specific characteristics
of UI handlers in comparison to Web browsers are:
• UI handlers in AAL spaces might use modern middleware to utilize I/O channels
distributed in an AAL space instead of being limited to only locally available drivers;
• Compared to the Web, the UI framework for AAL spaces might move easier beyond HTML,
which is not really modality- & layout-neutral, and make use of the results of activities, that
target the development of applications beyond the browsing of Web pages.
4.3 Dialog descriptions
The most important part of UI requests is the description of the dialog that an application is
asking to be held with a certain user. Such a description shall be device-, modality- and
layout-independent in order to guarantee a clear separation between application logic, on one
side, and presentation mechanisms used by the UI handlers available in a given AAL space,
on the other side. There are several alternative specifications relevant for dialog descriptions;
this document builds on XForms 1.1. XForms scripts are XML documents basically formed
from two parts:
• a set of form Controls that define the structure of the form as to be presented to the
addressed human user; and
• a set of Model elements that mainly deal with the data involved in the intended interaction
from the viewpoint of the application.
The latter includes the data structures and types relevant for the form data as well as instance
data, such as hidden data or any initial values to be used when rendering the form or hidden
data. Form controls are linked with the XML elements in the model part via XPATH
expressions . In this way, the interpreter will know if any initial value is associated with a form
control at hand and which restrictions have to be applied to possible related user input.
The application of XForms in the universAAL UI Framework is not one-to-one due to the fact
that the UI framework specified in this document is part of a more complete specification on
_____________
Privacy-level of a channel denotes its appropriateness for private communication when several people are in
the location where interaction takes place.
See http://www.w3.org/TR/xpath/. XPATH expressions can be used to refer to the XML elements and attributes
in an XML document.
– 16 – IEC PAS 62883:2014  IEC 2014
application-to-application interoperability within AAL spaces, in which data sharing plays a
substantial role. For this reason, universAAL had to rely on the Semantic Web specifications
and used the Resource Description Framework (RDF) as the de facto standard for
representing shared data in a domain-independent way. According to the Semantic Web
specifications, the domain-specific model underlying RDF data (data represented in RDF) can
then be specified using the Web Ontology Language (OWL). By relying on the combination of
RDF and OWL, universAAL specifications already cover many of the features assumed for the
model part of XForms. For example, the type system embedded in XForms Model is inherently
supported in a more powerful way in universAAL because of using OWL-based ontologies.
Therefore, the UI Framework of universAAL uses XForms specification just for the purpose of
specifying a dialog package that consists of the equivalents of XForms controls; the data
section of XForms is then replaced by RDF resources or OWL individuals originally used by
universAAL applications.
The dialog package of universAAL embeds both the form controls and the form data in a
single RDF resource of type “Form”, as illustrated by Figure 13.

Figure 13 – The dialog package based on the notion of a form
Characteristics of this package are :
• The dialog package is only inspired by XForms and does not provide any one-to-one
implementation of the original set of form controls:
– Originally, there is no hierarchical relationship between the form controls in XForms;
the provided class hierarchy is the result of analyzing the nature of those controls.
_____________
http://www.w3.org/standards/semanticweb/
http://www.w3.org/RDF
http://www.w3.org/2004/OWL
Please refer to API Documentation available under http://depot.universaal.org/ for a complete documentation of
this package. This API documentation exists in terms of Java API docs; the documentation of the dialog
package can be accessed by navigating to the package org.universAAL.middleware.ui.rdf.

– For some form controls in this package such as Sub-dialog Trigger and Media Object,
there is no direct counterpart in the XForms original set of form controls.
• There are four types of dialogs in universAAL like Figure 14 shows:
– System menu: the main menu assumed to be provided by a specific component of the
UI framework, called the Dialog Manager, that provides an entry-level access to the
available AAL services and applications.
– Ordinary / standard dialog: to be used when the application wants to wait for a related
input event upon which the application might decide whether to finish the interaction
with the user or proceed to a next dialog.
– Message: to be used when the application does not expect any input from the user as
long as it can be sure the message will be delivered to the user and acknowledged by
him or her.
– Sub-dialog: to be used for constructing a hierarchy of running dialogs to ensure that
control is returned to the parent dialog whenever a sub-dialog is finished.
System Menu Message
S
u
b
Main group Main group
m
of I/O controls of I/O controls
i
t
s
Standard buttons
Subdialog Standard Dialog
S S
u u
b b
Main group Main group
m m
of I/O controls of I/O controls
i i
t t
s s
Standard buttons
Figure 14 – A possible graphical visualization of
the mapping between dialog types and the predefined standard groups
• Depending on the dialog type, a form in universAAL will consist of different combinations
of the following predefined groups:
– submits: “buttons” that finish the dialog intended by the current form should be added
to this group;
– ioControls: all other form controls, no matter if input or output controls, subgroups or
even submits that trigger a sub-dialog should be added to this group;
– stdButtons: this group is reserved for a dialog management solution that has access to
all dialogs and may be willing to add standard buttons beyond the application logic to
reflect a system-wide behaviour.
The reference implementation of the universAAL dialog package incorporates additionally the
following features:
• The data part of the forms is hidden to the UI handlers so that they are relieved from error-
checking when users provide input: UI handlers simply try to store user input provided in
the context of a certain form control to that control element; if this attempt fails, the UI
handler shall give some hint to the user using the alert message set by the application
with the same semantic as defined by XForms.
• When a UI handler finishes a dialog, the data section of the form is automatically added to
the response to be provided to the UI broker.

– 18 – IEC PAS 62883:2014  IEC 2014
• Form controls can be generated by the dialog package automatically based on ontological
knowledge associated with the data.
4.4 The Adaptation Concept
4.4.1 Overview
The separation of the application and presentation layers based on introducing a brokerage
mechanism in-between makes it possible to provide an efficient and effective approach to the
accessibility and adaptivity challenges in the AAL domain. This approach is based on the
division of the adaptation tasks between the three parties in a natural way:
• Applications may concentrate on adaptivity in control and in content composition, for
example by sorting the application data to be presented to a user in a personalized and
situation-ware way;
• UI handlers may concentrate on adaptation in rendering by taking the characteristics of
the used channels into account; and
• The brokerage mechanism residing in-between may concentrate on the selection of the
right UI handler for a given user in a given situation.
All the three layers can benefit from the universAAL framework for supporting adaptivity, both
in terms of context-awareness and personalization, by subscribing for relevant contextual data
and / or fetching such data. Figure 15 provides an overview of the corresponding set of
components that comprise the universAAL framework for supporting adaptivity as an
extension to the universAAL bus system (see footnote 4). Further discussion of this part of the
universAAL platform is not in the scope of this specification.

Figure 15 – The universAAL framework for supporting adaptivity, which builds on top of
the universAAL context and service buses (see footnote 4)
4.4.2 Responsibilities of Applications
Applications can prepare the content to be presented to the user in an adaptive way before
adding it to a form object. Behaviour related to preparing the content in a personalized and
situation-aware way is a choice that shall be made by the application developer and the UI
framework cannot influence this behaviour largely. Here, the expectation is that the platform
as a whole provides means for supporting adaptivity, quite similar to the universAAL
framework outlined in Figure 15.
Applications shall contribute to the adaptivity of the UI framework as a whole. To enforce this,
the framework requires that applications provide the following data items when making a UI
request:
• Addressed User: the specific user whom the application wants to reach.
• The dialog priority: one of none, low, middle, high, or full; it will be ignored if at the time of
receiving the UI Request no other dialog is running that involved the same user as the one
addressed; otherwise, it will be used to determine whether the running dialog should be
interrupted; if the running dialog shouldn’t be interrupted, the request will be put in a
queue sorted according to the dialog priority and time of arrival.
• The content language: a value of type language [6] as defined in the specification of XML
Schema.
• The privacy level of the content: one of insensible, known_people_only, intimates_only,
home_mates_only, or personal.
Applications shall also contribute to the rendering phase by providing alternative versions of
any media objects used as content in the intended dialog. For this purpose, they shall rely on
a specific component of the universAAL UI framework, known as the Resource Manager (see
the specification of the RM in Section 4.5.4), by:
• referring in a generic way to a class of alternative media in dialog descriptions instead of
referring to concrete resources; and
• providing the RM with several different versions of the media objects along with specific
metadata, each for a specific runtime context.
4.4.3 Responsibilities of UI handlers
As components that utilize certain output channels for holding dialogs with human users, UI
handlers shall adapt the modality- and layout-neutral description of dialogs to the capabilities
of the devices that realize the utilized output channels. For performing such adaptation these
rules shall be followed:
• The profiles of the devices that realize the output channels may be stored in the database
of shared facts as indicated in Figure 15 (see in the same Figure also the component
called Profiling); alternatively, the developer of a UI handler may rely on the API of the
device driver used.
• The adaptation to the channel capabilities will necessitate transformations (e.g., text to
speech) and layout-related decisions (e.g., the order of going through the dialog elements
if a “one-dimensional” device such as a loudspeaker is being used for rendering the
dialog). This specification makes no assumptions about the relationship of UI handlers to
possible related transformation and rendering tools. From the perspective of the whole
universAAL platform, it is recommended to decouple such auxiliary software and utilize
their capabilities as shared services over the universAAL service bus (see footnote 4).
• The adaptation of media objects to the capabilities of the used devices needs the help of
application developers or third parties. If the application developer does contribute and the
dialog description contains references to the Resource Manager (see the recommendation
to application
...