RE: Questions regarding MMI

Wolfgang,

thank you for your comments and questions on the current MMI
architecture working draft
http://www.w3.org/TR/2008/WD-mmi-arch-20080414. 

The current working draft leaves open some issues which you are raising
in your email, like the startup phase and especially how components find
each other. The MMI working group will work on these particular issues
in the future and enhance the architecture document. For the moment we
assume that the interaction manager/runtime framework knows about the
modality components. 

Your point about the picture D.1 is valid. The URL to the SCXML document
should not be provided by the modality component. We think that it
should be configured somewhere within the framework. Thanks for pointing
this out.

Depending on the complexity of the application the interaction manager
might be decomposed into different modules. One possible decomposition
could follow the modularization of figure 2 or 3 of
http://www.w3.org/TR/mmi-framework/. But depending on the application
other decomposition schemes may be useful. The decomposition of the
interaction manager is currently not in focus of the MMI architecture
specification, thought the working group has already considered to cover
this issue in a  future version or a separate document. But practical
implementations certainly need to solve this problem.

We should also mention at this point that the MMI architecture does not
mandate that the interaction manager has to be implemented using an
SCXML interpreter (and hence authored using SCXML at all). But SCXML is
certainly a good choice. Even though it is possible to code the complete
SCXML state machine into one file it is certainly useful to decompose
the state machine into different files. This allows reusablilty and
structures the code.

The EMMA 1.0 specification covers input only. Future versions of EMMA
may cover representation of output as well. The behaviour of modality
components has to be controlled using the life-cycle event API. The
interaction manager might send a startRequest to a modality component to
enforce it to do something. If the modality component supports scripting
a "contentURL" (e.g. a URL to a VoiceXML script) might be passed with
the startRequest. Other modality components might not be scriptable. In
this case an API (i.e. a set of commands) has to be defined. These
commands could go into the <data> tag of the startRequest. The working
group currently prepares a document (which will probably be published as
an Appendix to the next version of the architecture working draft) which
describes how to define a modality component. This document will
hopefully cover a lot of your questions.

We also like to point you to the Working Group Note "Authoring
Applications for the Multimodal Architecture"
(http://www.w3.org/TR/mmi-auth) which shows a simple practical
implementation of the Multimodal Architecture and provides a sample
application. Some of your questions might also be answered there. 

Again thanks for your questions and comments.

Ingmar Kliche

on behalf of the Multimodal Working Group
 

-----Original Message-----
From: www-multimodal-request@w3.org
[mailto:www-multimodal-request@w3.org] On Behalf Of Wolfgang Rabl
Sent: Wednesday, May 07, 2008 5:32 PM
To: www-multimodal@w3.org
Subject: Questions regarding MMI


Hello,

My name is Wolfgang Rabl and i am a master student at the university of
Klagenfurt.
For my master thesis i have to implement a smarthome prototype where
devices within the home can be controlled by a pc or a smartphone and
through different input modalities.

During my research i found the W3C MMI framework and i think it looks
very promising, but i have a few questions regarding your draft.

I am not sure how to handle the startup phase when there are no
devices/modalities connected with the runtime framework. So how should
one modality component (for Example a GUI on a PDA) connect itself? As i
could see in your draft this may occur by using the NewContextRequest
Event? Now a new context should be created using a SCXML that represents
the application, but who provides this file? In
http://www.w3.org/TR/2008/WD-mmi-arch-20080414 D.1 it looks like the
file that initializes the interaction manager is provided within the
source parameter of the NewContextRequest event. But is it correct that
the Modality component delivers the interaction model information?

I am not quite sure about the information contained within these SCXML
document, during my research i found some information that there should
be a distinction between the controlling of modality components and the
control of the application flow, is this right? so there is a single
SCXML definition for the coordination of the modality components and
further SCXML documents for the control of the diferent running
applications/contexts? Or should one File contain all the information?

During the execution of the SCXML document new modalities get started by
using startRequest events. But how does the interaction manager know
something about other connected modality components? So far only the
first modality component (the PDA GUI) communicated with the interaction
manager. Is there a further step at the beginning where all the modality
components register themself (login?) Should this also be handled by the
interaction manager?

So if the components are up and running, how does a new modality
component connect itself to them same context?  Maybe the same user that
belongs to the PDA wants to start a second GUI or some other modality on
a PC. Is this also the purpose of the newContextRequest event? As i read
the specification the new component would end up getting a new context
and would not connect to the one allready running?

User input gets represented as EMMA documents. So if the user wants to
change something within the application his input gets converted into
EMMA representation and is passed over to the application. But what
happens if there are some changes in the application? how is this
information transportet to the modality components? As far is i can see
EMMA is only for user input and not for application output.

I would really like to implement my prototype using your MM Architecture
so i would appreciate any help you could offer me.

Thanks and best regards,
Wolfgang Rabl

Received on Monday, 7 July 2008 12:39:07 UTC