Review comments Discovery & Registration of Multimodal Modality Components sections 4-

Hey there,

Here are some more comments on sections 4-8


4 A manager to handle the state of the resources of the multimodal system
-------------------------------------------------------------------------

This manager is responsible for handling the evolution of the "multimodal session"
--> If session is such a fundamental concept, it should also appear in the vocabulary. What is the difference of a session to interaction context?

This component is also aware of the system's capabilities, like the address of modalities, their availability or their processing state.
--> There are substantial differences between the MMI Framework and the MMI Architecture. Does this standard aim at paving the way for the MMI Framework to be a recommendation? If yes, which components, apart from the session component, of the MMI Framework play a role in this context and why?
So far it was solely stated that this document extends the MMI Architecture. I find the appearance of the MMI Framework as a central entity at this stage pretty confusing. Is the notion of the MMI Framework really needed?

The Resources Manager keeps the control of the global state and the resources of the system in a unified layer with the control of the user interaction (Interaction Manager). 
--> global state is vague and maybe confused with the state of the interaction which is under the responsibility of the interaction manager

Figure 2:
RM for resources manager is missing in the legend

4.1 The Resources Manager and the MVC design pattern of the MMI Architecture
----------------------------------------------------------------------------

The Resources Manager proposed in the current document...
--> a standard should not propose something

The Resources Manager translates the user's actions into method calls on the Data Component, as the MVC pattern proposes.
--> The responsibilities of interaction manager and resources manager should be put clearer, espacially: What was the responsibility of the IM according to the MMI architecture and what is it now? 


4.3 Data structures handled by the Resources Manager
----------------------------------------------------

The image of the current state
--> do you mean the current configuration?

The type and values of these structures is implementation-dependent.
--> this applies to all data structures. Should this be mentioned before going into details?

4.4 Requirements Addressed
--------------------------

The State Manager supports the coordination between distributed agents...
--> What is the state manager? How does it differ from the resources manager?
--> What is an agent? Can this be expressed by the already introduced components?

...and their communication through the control layer.
--> Is the control layer always the topmost interaction manager or can this also appear on lower hierarchy levels?

...and also enhances the resolution of input conflicts from distributed modalities 
--> This would mean that the resources manager has the capabilities of a multimodal fusion engine. I have concerns that this would go beyond the targeted capabilities

 It handles all the communication between the Modality Components and the registry handled by the Data Component, and it manages the multiple renderings of private and public data related to the state of the multimodal system or the state of the interaction cycle.
 --> The meaning of this sentence is hard to get. Could this be better split up in multiple sentences?
 
 5. A bidirectional flow of messages
 -----------------------------------
 
...which means that if there is an HTTP client-server implementation, it must be designed following a push notification technique.
--> no need for a restriction to HTTP

In the communication protocol designed for the MMI life-cycle events ...
--> external link should be at first appearance (1 paragraph above)

Our proposal aims to cover a the flow of messages...
--> again a proposal

For this reason, our tunable communication strategy offers significant advantages for optimizing querying.
--> sounds like an academic advertisment. could be "For this reason, a tunable communication strategy offers significant advantages for optimizing querying."

6. Two events for system updates
--------------------------------

We propose a renewal mechanism based
--> again a proposal

the checkUpdate Event and the UpdateNotification
--> For consistency checkUpdate should be capitalized CheckUpdate

The checkUpdate Event is provided
--> The CheckUpdate event provides...

On the other hand, the UpdateNotification is proposed:
--> The UpdateNotification provides...

6.1 The timeout attribute for state handling and registration renewal
---------------------------------------------------------------------
We propose a dedicated data structure for registration: the timeout attribute. A timeout is an ordered list of three elements:
--> No proposal
 The timeout attribute is a dedicated data structure for registration. A timeout is an ordered list of three elements:
 
Figure 6
The data component is asked to log the request. So far no logging has benn defined. Neither in this document nor in the MMI Architecture. Do you mean updating the stored image?

With our proposal,...
--> I still have problems regarding this as a proposal

6.2 CheckUpdateRequest and CheckUpdateResponse
----------------------------------------------

The CheckUpdate events are the request/response pair, CheckUpdateRequest and CheckUpdateResponse. CheckUpdateRequest and CheckUpdateResponse are used to check to see if there
--> The CheckUpdate events are the request/response pair, CheckUpdateRequest and CheckUpdateResponse. CheckUpdateRequest and CheckUpdateResponse are used to check if there 

6.2.1 UpdateType
----------------

An attribute that MUST indicate the type of check to be performed. Some values can be: Handshake, Monitoring, Reporting, DataCheck, Resuming, Leaving
--> If this list is only a suggestion: Who defines the values that are actually used? Where are they defined? Are they application specific?

6.2.2 State
-----------

Some values can be: Alive, Loading, Registering, Available, Idle, Busy Waiting, Processing, Unavailable, Unregistered.
--> If this list is only a suggestion: Who defines the values that are actually used? Where are they defined? Are they application specific?
--> How are the states related to the modality component states as defined at https://www.w3.org/TR/mmi-arch/#d3e1652 ?
--> What happens, if an unregistered modality component receives a StartRequest?

6.2.2.7 PROCESSING
------------------

Should this have a relation to the number of tasks that this MC can handle in parallel?

6.2.2.9 UNAVAILABLE
-------------------

A Modality Component MUST be in Unavailable state when it has a failure, or when it is unregistered and it does not update its registration, or when it lacks of resources or must reload them. In short, when the Modality Component is no more able to correctly ensure its task.
--> Does this include sending updates to the RM about the state change?

The following list shows the flow between these states:
--> does this still belong to the description of the unvailable state?

6.2.3 AutomaticUpdate
---------------------

What happens, if the resources manager as the target of the communication becomes (temporarily) unavailable?
Who defines the interval between periodic updates? If the RM is responsiple for the traffic (section 6.1), leaving this to the MC could violate this concept

6.2.4 Metadata
--------------

Can the data attribute be reused? Why is an extra attribute needed?

6.3 UpdateNotification
----------------------

The UpdateNotification event informs other system components (periodically or not) about the changes on the state of a Component.
--> Is it possible to have periodic state changes?

6.2.3 Timeout
-------------

Again: Is it the responsibility of the MC to define the update frequency?

6.4 Requirements Addressed
--------------------------

I find this section confusing. What is the difference to section 4.4? Why does it appear after the new events and the other one before?

7. Open Issues
--------------

Services are mentioned in section 2 and are also motivated in the MVC pattern in section 4.1. However, I did not find anything that is suitable to expose the functionality of an MC. Shouldn't this be a part of querying? Given the introduced message pairs, I still have to know, which functionality is exposed by which MC. I can query if it is available, but I cannot check, e.g., if there is another MC that could provide similar functionality. This can be an issue in dynamic systems where new devices can be introduced into the system that replace others. For instance, I could replace a combined speaker/microphone MC with two distinct MCs. 1 for a speaker and 1 for a microphone. Introducing an upper MC as IM to these will not help much since it couples bothe which is not needed in all cases. In this example, the availability of an audio output MC does not require the presence of an audio input MC.

8. Acknowledgments
------------------

The authors wish to acknowledge the contributions by all the members of the Multimodal Interaction Working Group, in particular, Kazuyuki Ashimura, the W3C Team Contact for the Working Group
--> It is nice to mention him here, but he is also one of the authors.

Received on Tuesday, 29 November 2016 14:53:31 UTC