Multimodal Architectures and Interfaces: Candidate Recommendation Disposition of Comments
- This version
- Mon Jul 16 16:14:28 EDT 2012
- Editor
- Jim Barnett, Genesys
This document details the responses made by the Multimodal Working Group to issues raised during the Candidate Recommendation period (beginning on January 25, 2012). www-multimodal@w3.org(archive) mailing list.
This document of the W3C's Multimodal Working Group describes the disposition of comments as of July 16, 2012 on the Candidate Recommendation Multimodal Architecture and Interfaces Version 1.0. It may be updated, replaced or rendered obsolete by other W3C documents at any time.
For background on this work, please see the Multimodal Interaction Activity Statement.
Legend:
| ACCEPTED | Comment was accepted |
| TEXTSUPERSEDED | Text that was commented on had already been changed. |
| CLARIFICATION | Comment only required a clarification. |
| DROPPED | Feature in question was removed from the spec. |
| REASSIGNEDID | Issue number was changed to a new ID |
Results:
| ID | Title | Date Opened | Last Updated | Disposition | Acceptance | Related Issues |
|---|---|---|---|---|---|---|
| ISSUE-203 | typos in XSD | 2012-05-15 | 2012-05-21 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-204 | mc specific assertions for cancel | 2012-05-31 | 2012-06-11 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-205 | modality component states | 2012-05-21 | 2012-06-12 | CLARIFICATION | IMPLICIT | NONE |
| ISSUE-206 | Appendix A: Modality State Components | 2012-05-30 | 2012-06-11 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-207 | Description of Done Notification | 2012-05-30 | 2012-06-11 | ACCEPTED | EXPLICIT | NONE |
| ISSUE-208 | Confidential Flag | 2012-06-01 | 2012-06-11 | CLARIFICATION | EXPLICIT | NONE |
From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Tue, 15 May 2012 10:23:20 +0200 Message-ID: <1337070200.2833.11.camel@homer-simpson.localdomain> To: www-multimodal@w3.org Hey there, currently, I am about to implement a generic hook of a voice modality component for JVoiceXML. This hook will open source and will be available with the next release of my open source voice browser. I started with the XSD definitions that are given in appendix C of http://www.w3.org/TR/2012/CR-mmi-arch-20120112/ I know that the comments are no longer welcome but there are some upper-lower case confusions in these XSD files. I assume that the element "statusInfo" defined in mmi-elements.xsd should be lower case, but some references are upper case. Occurences are in - C10 StartResponse.xsd - C13 CancelResponse.xsd - C15 PauseResponse.xsd - C17 ResumeResponse.xsd - C22 StatusResponse.xsd Although these schemas are only informative they should be corrected. It is only minimal effort and will help to avoid further confusion. Thanks, Dirk From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Mon, 21 May 2012 09:28:36 +0200 Message-ID: <1337585316.2773.7.camel@homer-simpson.localdomain> To: Deborah Dahl <dahl@conversational-technologies.com> Cc: www-multimodal@w3.org Hey Debbie, thanks for the quick answer. I had a look at the submission process for implementation reports. I understand that you have some interest in having more experiences with the specification. I also saw that the deadline for submitting a multimodal implementation report was on 29 February 2012 (taken from http://www.w3.org/2002/mmi/2012/mmi-arch-irp/Overview.html#participate) So that deadline was already extended? For JVoiceXML I will not be going the whole way but implement only a voice modality component. Will that be sufficient? I assume that I will have to fulfil at least the "common test assertions" and the "MC-specific test assertions" as described in http://www.w3.org/2002/mmi/2012/mmi-arch-irp/Overview.html#participate Will I be linked somewhere (to get something back at least)? Best, Dirk Am Dienstag, den 15.05.2012, 18:24 -0400 schrieb Deborah Dahl: > Hello Dirk, > Thanks for your comments on the MMI Architecture draft. Even though we're in the Candidate Recommendation period, we can fix typos like this in the next draft, which will be a Proposed Recommendation. > If you're close to completing your implementation of the MMI Architecture, you might want to consider submitting an implementation report. These reports help support the spec by demonstrating broad interest, and also help us understand what features people are most interested in. > The process is described in http://www.w3.org/TR/mmi-arch/. > Regards, > Debbie Dahl > MMI Working Group Chair DISPOSITION=ACCEPTED ACCEPTANCE=IMPLICIT
DISPOSITION=ACCEPTED ACCEPTANCE=IMPLICIT
From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Thu, 31 May 2012 20:27:57 +0200 Message-ID: <bj5nxs7sg2fifcdgt99f99uo.1338488588567@email.android.com> To: www-multimodal@w3.org Hey there, What is the difference between assertion 178 (a modality component MUST return a CancelResponse event in response to a CancelRequest) and assertion 24 (CancelResponse MUST be sent by the modality component as a response to the CancelRequest)? Dirk Hi Dirk, We've discussed your question in the Working Group, and we agree with your suggestion that test assertions 178 (a modality component MUST return a CancelResponse event in response to a CancelRequest) and assertion 24 (CancelResponse MUST be sent by the modality component as a response to the CancelRequest) are basically duplicates. We plan to remove assertion 24 and republish the Implementation Report Plan. Since we are tracking all comment threads at this point, please let us know by June 15 if this resolution is acceptable, otherwise we will assume that you agree with our decision (but it is very helpful to have an explicit response). Best regards, Debbie Dahl, MMI WG Chair From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Mon, 11 Jun 2012 19:01:24 +0200 Message-ID: <w4wt09kkmjvff8ad2jkp5amd.1339434009370@email.android.com> To: Deborah Dahl <dahl@conversational-technologies.com> Cc: www-multimodal@w3.org Hey Debbie, Yes, this solution is acceptable. Dirk Deborah Dahl DISPOSITION=ACCEPTED ACCEPTANCE=EXPLICIT
DISPOSITION=ACCEPTED ACCEPTANCE=EXPLICIT
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 From: Wiechno Piotr - Korpo TP <Piotr.Wiechno@orange.com> Date: Tue, 12 Jun 2012 07:19:25 +0000 To: "'www-multimodal@w3.org'" <www-multimodal@w3.org> Message-ID: <6AB71B17D0078548B70E9F06AF67BC62734166CC@OPE10MB04.tp.gk.corp.tepenet> 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 DISPOSITION=CLARIFICATION ACCEPTANCE=IMPLICIT
DISPOSITION=CLARIFICATION ACCEPTANCE=IMPLICIT
From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Wed, 30 May 2012 09:54:13 +0200 Message-ID: <1338364453.2633.12.camel@homer-simpson.localdomain> To: www-multimodal@w3.org Hey there, the term "ignore" in the table at http://www.w3.org/TR/mmi-arch/#d3e1824 is misleading. The request should not be ignored but does not lead to a state transition. According to http://www.w3.org/TR/mmi-arch/#LifeCycleEvents most requests MUST result in sending a response. IMHO, a better description would be "no transition" or "remain in state". Dirk From: Deborah Dahl <dahl@conversational-technologies.com> Date: Wed, 6 Jun 2012 11:19:00 -0400 To: <www-multimodal@w3.org> Message-ID: <010a01cd43f7$b700d2c0$25027840$@conversational-technologies.com> Hi Dirk, We've discussed your question in the Working Group, and we agree with your suggestion that we should not say that an MC ignores a request because responses are, as you point out, required for most requests. It would be better to say "no transition" or "remain in state". We will clarify the spec accordingly. Since we are tracking all comment threads at this point, please let us know by June 15 if this resolution is acceptable, otherwise we will assume that you agree with our decision (but it is very helpful to have an explicit response). Best regards, Debbie Dahl, MMI WG Chair From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Mon, 11 Jun 2012 10:03:11 +0200 Message-ID: <1339401791.1916.4.camel@homer-simpson.tk.informatik.tu-darmstadt.de> To: Deborah Dahl <dahl@conversational-technologies.com> Cc: www-multimodal@w3.org Hey Debiie, this solution is fully acceptable. Dirk DISPOSITION=ACCEPTED ACCEPTANCE=EXPLICIT
DISPOSITION=ACCEPTED ACCEPTANCE=EXPLICIT
From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Wed, 30 May 2012 09:50:46 +0200 Message-ID: <1338364246.2633.8.camel@homer-simpson.localdomain> To: www-multimodal@w3.org Hey there, IMHO the Target of a DoneNotification is not specific enough. The specification states that an MC must return a DoneNotification to the IM. It should be concretized by If the Modality Component reaches the end of its processing, it MUST return a DoneNotification to the IM that issued the StartRequest. I have the impression that the current statement does not reflect that IMs may be used as nested components within other IMs. This way, it may be the case that a single MC may be addressed by multiple IMs at the same time. In fact, the overall architecture will be rather a graph than a tree. This would mean that there will not be "the IM" as it is stated throughout the specification. Dirk From: Deborah Dahl <dahl@conversational-technologies.com> Date: Wed, 6 Jun 2012 11:19:00 -0400 To: <www-multimodal@w3.org> Message-ID: <010901cd43f7$b6e20020$24a60060$@conversational-technologies.com> Hi Dirk, We've discussed your question in the Working Group, and we agree with your suggestion that it would be clearer to say "If the Modality Component reaches the end of its processing, it MUST return a DoneNotification to the IM that issued the StartRequest" since an MC may be handling requests from several IM's. We will clarify the spec accordingly. Since we are tracking all comment threads at this point, please let us know by June 15 if this resolution is acceptable, otherwise we will assume that you agree with our decision (but it is very helpful to have an explicit response). Best regards, Debbie Dahl, MMI WG Chair From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Mon, 11 Jun 2012 10:01:49 +0200 Message-ID: <1339401709.1916.2.camel@homer-simpson.tk.informatik.tu-darmstadt.de> To: Deborah Dahl <dahl@conversational-technologies.com> Cc: www-multimodal@w3.org Hey Debbie, this resolution is fully acceptable. Dirk DISPOSITION=ACCEPTED ACCEPTANCE=EXPLICIT
DISPOSITION=ACCEPTED ACCEPTANCE=EXPLICIT
From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Fri, 01 Jun 2012 06:21:40 +0200 Message-ID: <cntxxlfi2o4kmxgwop7ar646.1338488931153@email.android.com> To: www-multimodal@w3.org Hey there, I am not able to implement assert 149 since the specification does not state explicitly what is meant by "the information" that should not be logged. There are several possible interpretations: - the request/response messages - any further action that is taken in response to the confidental request Also: How should an MC deal with it, if is also an IM and creates new events in response to this confidental request? Should these requests also be confidental? Unfortunately, the spec does not seem to be precise enough at this point so that I see no chance for me to implement the confidental support. Dirk From: Deborah Dahl <dahl@conversational-technologies.com> Date: Wed, 6 Jun 2012 11:19:00 -0400 To: <www-multimodal@w3.org> Message-ID: <010c01cd43f7$b74778b0$25d66a10$@conversational-technologies.com> Hi Dirk, We've discussed your question about the confidential flag in the Working Group. Our intention was that the exact interpretation of the confidential flag would be implementation-specific. However, it's also worth pointing out that this feature was called out as "at risk" in the Candidate Recommendation spec, due to a potential lack of implementations. If we don't get two implementations of this feature it will be removed from the spec. Since we are tracking all comment threads at this point, please let us know by June 15 if this resolution is acceptable, otherwise we will assume that you agree with our decision (but it is very helpful to have an explicit response). Best regards, Debbie Dahl, MMI WG Chair From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Mon, 11 Jun 2012 10:13:37 +0200 Message-ID: <1339402417.1916.13.camel@homer-simpson.tk.informatik.tu-darmstadt.de> To: Deborah Dahl <dahl@conversational-technologies.com> Cc: www-multimodal@w3.org Hey Debbie, I am not sure if this really removes my problems with the interpretation of the specification. Although it is considered to be at risk of removal, the specification should be clear about the intention. Maybe, you should add that the implementation is application specific. I really miss that in the specification. Also, I am not sure if all those possible behaviors (I mentioned some possible interpretations in my first email) can be toggled by a simple switch. Especially, if you want to support more than one of those behaviors at the same time. >From that point of view this solution is not acceptable, sorry. Maybe, adding that hint that the interpretation of the confidential is application specific and further hints can be submitted in the data field could help to overcome this weakness. As a consequence the hint about logging should be removed since this is only one possible interpretation. Maybe, it could still serve as an example? Best, Dirk From: Deborah Dahl <dahl@conversational-technologies.com> Date: Mon, 11 Jun 2012 12:23:34 -0400 To: "'Dr. Dirk Schnelle-Walka'" <dirk.schnelle@jvoicexml.org> Cc: <www-multimodal@w3.org> Message-ID: <03b501cd47ee$8d41f130$a7c5d390$@conversational-technologies.com> Hi Dirk, The MMI Working Group has discussed your questions. We agree that it would be good to clarify that the interpretation of "confidential" is application-specific. However, there are two possible eventualities. 1. If we do get two implementations of the "confidential" attribute, the feature will be included in the spec, and the next version of the spec (the Proposed Recommendation) will include clarifying language that emphasizes that the meaning of "confidential " is application-specific. 2. If we don't get two implementations of the "confidential" attribute, the feature will be removed from the spec altogether, and consequently we won't need any clarifications. Thanks again for your comments, and also thanks for your quick response to our proposed resolutions. As with your earlier questions, please let us know before June 15 whether or not you accept this proposal. Best regards, Debbie Dahl From: Dr. Dirk Schnelle-Walka <dirk.schnelle@jvoicexml.org> Date: Mon, 11 Jun 2012 20:05:42 +0200 Message-ID: <kbtvng2vrogppxt30hm1g8s9.1339437942603@email.android.com> To: www-multimodal@w3.org -------- Originalnachricht -------- Betreff: RE: [arch] confidental flag Von: "Dr. Dirk Schnelle-Walka" <dirk.schnelle@jvoicexml.org> An: Deborah Dahl <dahl@conversational-technologies.com> Cc: Hey Debbie, The solution is acceptable if the spec will be updated accordingly if the confidential flag will not be removed. It still needs some more details, but I can understand that you want to shift that work. Dirk DISPOSITION=CLARIFICATION ACCEPTANCE=EXPLICIT
DISPOSITION=CLARIFICATION ACCEPTANCE=EXPLICIT