Re: modality component states

Dirk,

We've discussed your questions about the modality component state diagram and status messages in the MMI Working Group. As with all other comments, please let us know by June 15 if this resolution is acceptable, otherwise we will assume that you agree with our answer.

Question #1 (MC state diagram): 

The UML diagram illustrates how an Interaction Manager can interpret the behavior of a Modality Component within a specific interaction context. The architecture specification doesn't define MC (or IM) states, just the Lifecycle Event interface. Thus, 'Running', 'Paused' and 'Idle' are just concepts that describe how a Modality Component functions from the Interaction Manager's perspective. A Modality Component could provide a diagram and table such as the one in Appendix A to document how it responds to Lifecycle Events, what error messages it may send and when, etc.

The states are not necessarily related to inner implementation details of a Modality Component. A transition to 'Running' on a StartRequest event does not imply that the MC has actually started processing a task, only that it has received and acknowledged the StartRequest message, and is thus considered by the IM as 'running'.

To reiterate, the diagram illustrates a Modality Component's reactions to an Interaction Manager's actions in a specific context. This has two implications:

a) The diagram shows only transitions which result from processing of Lifecycle Events sent from the IM to the MC. As a message sent by the MC, DoneNotification is not covered by the diagram. We could add a sentence to Appendix A noting that if the IM receives a DoneNotification message from a 'running' Modality Component, it may consider it as switched to 'idle', although that may depend on the application.

b) Both the 'Initial' and 'Terminate' states refer to a specific interaction context, not the uptime of the component. The initial state is entered only after a context has been established (which is why there is no NewContext message on the diagram). The ClearContext message is the only way to get to 'Terminate', which means terminating the session specified by the context, not killing the component. Starting and stopping specific tasks within an established context is handled through Start/Cancel/Prepare/Pause messages. An Interaction Manager has no means to start or shut down Modality Components outside of interaction context.

Questions #2 and #3 (status messages and automatic updates): 

How status messages are handled is application-specific, and should be described in a component's documentation. Note that the automatic update feature is marked as at risk of removal due to potential lack of implementations.

Regards,

Piotr Wiechno
Orange Labs Poland

------------------------

From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> 
Date: Mon, 21 May 2012 10:50:53 +0200
Message-ID: <1337590253.2773.25.camel@homer-simpson.localdomain> 
To: www-multimodal@w3.org 

Hey there,

I continued my work on support for the MMI pattern for JVoiceXML and
need some clarification:

Appendix A http://www.w3.org/TR/mmi-arch/#d3e1824 was quite helful in
understanding when to send failure and success messages. Although this
section is declared to be only informative, I was wondering if the UML
diagram below the table is somewhat incomplete. As far as I understood,
the transition from RUNNING to Terminate should also be possible with a
DoneNotification. This is the case, when the modality component
terminates normally. As the ClearContextRequest (currently the only
guard condition) is optional, there must be some other means to
terminate a running modality.

A question in the same direction:
StatusRequest messages http://www.w3.org/TR/mmi-arch/#d3e1824 are
supposed to send ACTIVE if the context (if provided) is still active.
This would include the states IDLE, PAUSE and RUNNING. What shall happen
if the modality component terminates and a client asked for periodic
updates (RequestAutomaticUpdate set to true)? Shall the modality
component contiue sending status update messages until a
ClearContextRequest is received? Is there a suggestion for a "good"
timespan between to StatusResposne messages? What are your expectations?

And a final one in this context:
What shall happen to a an automated update request if sending the status
update traps into an error, i.e. the target can not be reached. Shall
the MC continue trying sending updates? This may make not much sense if
the originator shut down and will never send a ClearContextRequest. This
would mean that the context will never be cleared. On the other hand,
the connection may be temporarily down and will be available again after
some time.

Best,
Dirk

Received on Tuesday, 12 June 2012 08:07:24 UTC