Multimodal Architectures and Interfaces: Last Call Working Draft Disposition of Comments
- This version
- 16 November 2011
- Editor
- Jim Barnett, Genesys
This document details the responses made by the Multimodal Working Group to issues raised during theLast Call Working Draft period (beginningJanuary 25, 2011 and ending February 15, 2011).www-multimodal@w3.org(archive) mailing list.
This document of the W3C's Multimodal Working Group describes the disposition of comments as of16 November 2011on theLast Call Working Draft 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 theMultimodal 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-187 | Pubic Comment 1 | 2011-03-27 | 2011-07-11 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-188 | Public Comment 2 | 2011-03-27 | 2011-07-11 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-189 | Public Comment 3 | 2011-05-23 | 2011-07-11 | ACCEPTED | IMPLICIT | NONE |
| ISSUE-190 | Public Comment 4 | 2011-05-23 | 2011-08-15 | CLARIFICATION | EXPLICIT | NONE |
| ISSUE-195 | qualified vs unqualified attributes | 2011-05-03 | 2011-05-16 | CLARIFICATION | EXPLICIT | NONE |
2011-03-27
2011-07-11
closed
Hallo,I have been reviewing the current specification. Even though it yet makesquite a mature impression I found some flaws that may should be revised.The .xsd files in Appendix C require a valid mmi-representation to havequalified attributes.------------------------------------------------------------attributeFormDefault="qualified"elementFormDefault="qualified"------------------------------------------------------------Given that it seems Appendix B is not in line with the spec.Examples there (see exerpt below) are not using qualified attributes.------------------------------------------------------------<mmi:newContextRequest source="someURI"requestID="request-1"></mmi:newContextRequest>------------------------------------------------------------On the other side examples in Appendix E are valid to the xsd definition:------------------------------------------------------------<mmi:startRequest mmi:requestID="1.237204761416E12"mmi:context="IM_dcc3c320-9e88-44fe-b91d-02bd02fba1e3"mmi:target="GUI"> <mmi:contentURL>login</mmi:contentURL> <mmi:data> <gui resourceid="login" xml:lang="de-DE"> <data enabled="false"/> <data enabled="false"/> </gui> </mmi:data></mmi:startRequest>------------------------------------------------------------
DISPOSITION=ACCEPTEDACCEPTANCE=IMPLICIT
2011-03-27
2011-07-11
closed
From: Jakob Sachse <jakobsa@gmail.com>Date: Sun, 27 Mar 2011 15:40:13 +0200Message-ID: <AANLkTinPmnF6pg8JBcpC96XemERQBU=ddKCYVpCDZEjJ@mail.gmail.com>To: www-multimodal@w3.orgHallo,I have been reviewing the current specification. Even though it yet makesquite a mature impression I found some flaws that may should be revised.Another minor issue I came across was that in Appendix F.2 the spec states:------------------------------------------------------------[...]The parameter timeout is optional and describes the maximum delayin milliseconds.[...]------------------------------------------------------------Whereas the following sequence diagrams are using seconds as time unit.------------------------------------------------------------timeout:e.g. 30 sec------------------------------------------------------------That's what I came across so far. Overall it is fair to say that theworking draft makes a good impression on me.
DISPOSITION=ACCEPTEDACCEPTANCE=IMPLICIT
2011-05-23
2011-07-11
closed
From: Jakob Sachse <jakobsa@gmail.com>Date: Mon, 23 May 2011 16:12:13 +0200Message-ID: <BANLkTi=GtYtYsyYZ814dU0aMM+tRKDXeKw@mail.gmail.com>To: www-multimodal@w3.orgHallo,as part of my effort to check mmi-arch I have used the xml schema tovalidate thethe examples. In some cases the examples where not valid against the xsd.So I went to the text to find out which (xsd or example) was correct.Unfortunatelythe text sometimes lacks this information.For example "6.2.1.1 NewContextRequest Properties" lists (among others)Target and Dataas possible Properties. Whereas Data explicitly is defined optional (in6.1.7) it's not clear fromthe text if Target is optional or mandatory (in 6.1.3). Only it is said thatthe value must bean address. The same goes for the Immediate property.
DISPOSITION=ACCEPTEDACCEPTANCE=IMPLICIT
2011-05-23
2011-08-15
closed
From: Jakob Sachse <jakobsa@gmail.com>Date: Mon, 23 May 2011 16:12:13 +0200Message-ID: <BANLkTi=GtYtYsyYZ814dU0aMM+tRKDXeKw@mail.gmail.com>To: www-multimodal@w3.orgHallo,Other specs often use tables to outline child elements and attributes. Iwould recommend using a table, too.One column of the table could define if a property is mandatory or optional.Also by using joint cellsmutually exclusive properties could be outlined well.Regards,Jakob.
DISPOSITION=CLARIFICATIONACCEPTANCE=EXPLICIT
2011-05-03
2011-05-16
closed
From: Jakob Sachse <jakobsa@gmail.com>Date: Tue, 3 May 2011 17:48:05 +0200Message-ID: <BANLkTinWBuXUkECHJRqeOrBaY05n67fP-Q@mail.gmail.com>To: www-multimodal@w3.orgHi,I have been rechecking my findings and found another point that i wouldlike to comment on.In contrast to what i wrote in my prior mail, not all .xsd files in AppendixChave attributeFormDefault and elementFormDefault set.- mmi.xsd (Appendix C.1)Neither has elementFormDefault = "qualified" on the schema elementnor form="qualified" on the mmi-element definition set. Since"unqualified" is the default value all mmi elements are to be usedunqualified only.This, as far as I know, makes most of the examples invalid as theyuse the mmi element in a qualified way.- mmi-datatypes.xsd (Appendix C.2)Does not have attributeFormDefault nor elementFormDefault set. Which makesit being set to the default value "unqualified". Types and Attributesdefined in thisxsd will have to be used without namespace prefix. But other .xsd documents(e.g.mmi-attribs.xsd (Appendix C.3)) reference them with prefix.I am not a great expert on the XML Schema spec but I think someone shouldlook intothis. One thing I had to find out (while investigating my findings) was thatelementFormDefault and attributeFormDefault won't get inherited by childdocumentsincluded in the parent documents.Any comments are welcome!Thanks & Regards,Jakob.2011/3/27 Jakob Sachse <jakobsa@gmail.com>Subsequent email:From: Jakob Sachse <jakobsa@gmail.com>Date: Mon, 16 May 2011 16:16:33 +0200Message-ID: <BANLkTimos=YTHD99xZycxN23U_DwMw2mig@mail.gmail.com>To: www-multimodal@w3.orgCc: Jim Barnett <Jim.Barnett@alcatel-lucent.com>, Ingmar Kliche <Ingmar.Kliche@telekom.de>I have an update on my comment on the mmi element which is used qualified.It was *my mistake* not to consider the difference between global and localelements.Global elements as mmi always have to be used qualified, regardless of thevalue ofelementFormDefault. Thats why the examples given are valid regarding thispoint.I am sorry for the confusion.Regards,Jakob.STATUS=CLARIFICATIONACCEPTANCE=EXPLICIT
DISPOSITION=CLARIFICATIONACCEPTANCE=EXPLICIT