W3C home > Mailing lists > Public > www-multimodal@w3.org > May 2012

modality component states

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.

Received on Monday, 21 May 2012 08:51:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:37 UTC