W3C

Multimodal Architectures and Interfaces: Last Call Working Draft Disposition of Comments

This version
16 November 2011
Editor
Jim Barnett, Genesys

Abstract

This document details the responses made by the Multimodal Working Group to issues raised during the Last Call Working Draft period (beginningJanuary 25, 2011 and ending February 15, 2011). www-multimodal@w3.org(archive) mailing list.

Status

This document of the W3C's Multimodal Working Group describes the disposition of comments as of 16 November 2011 on the Last 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 the Multimodal Interaction Activity Statement.

Comment summary

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

Issue detail

ISSUE-187 - Pubic Comment 1

Tracker (W3C Member only):

ISSUE-187

Opened:

2011-03-27

Last Updated:

2011-07-11

State:

closed

Description:

Hallo,

I have been reviewing the current specification. Even though it yet makes
quite a mature impression I found some flaws that may should be revised.

The .xsd files in Appendix C require a valid mmi-representation to have
qualified 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" target="someOtherURI"
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 id="back" enabled="false"/>
      <data id="next" enabled="false"/>
    </gui>
  </mmi:data>
</mmi:startRequest>
------------------------------------------------------------

Notes:

Related e-mails:

ISSUE-188 - Public Comment 2

Tracker (W3C Member only):

ISSUE-188

Opened:

2011-03-27

Last Updated:

2011-07-11

State:

closed

Description:

From: Jakob Sachse <jakobsa@gmail.com>
Date: Sun, 27 Mar 2011 15:40:13 +0200
Message-ID: <AANLkTinPmnF6pg8JBcpC96XemERQBU=ddKCYVpCDZEjJ@mail.gmail.com>
To: www-multimodal@w3.org

Hallo,

I have been reviewing the current specification. Even though it yet makes
quite 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 delay
in 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 the
working draft makes a good impression on me.

Notes:

Related e-mails:

ISSUE-189 - Public Comment 3

Tracker (W3C Member only):

ISSUE-189

Opened:

2011-05-23

Last Updated:

2011-07-11

State:

closed

Description:

From: Jakob Sachse <jakobsa@gmail.com>
Date: Mon, 23 May 2011 16:12:13 +0200
Message-ID: <BANLkTi=GtYtYsyYZ814dU0aMM+tRKDXeKw@mail.gmail.com>
To: www-multimodal@w3.org

Hallo,

as part of my effort to check mmi-arch I have used the xml schema to
validate the
the 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.
Unfortunately
the text sometimes lacks this information.

For example "6.2.1.1 NewContextRequest Properties" lists (among others)
Target and Data
as possible Properties. Whereas Data explicitly is defined optional (in
6.1.7) it's not clear from
the text if Target is optional or mandatory (in 6.1.3). Only it is said that
the value must be
an address. The same goes for the Immediate property.

Notes:

Related e-mails:

ISSUE-190 - Public Comment 4

Tracker (W3C Member only):

ISSUE-190

Opened:

2011-05-23

Last Updated:

2011-08-15

State:

closed

Description:

From: Jakob Sachse <jakobsa@gmail.com>
Date: Mon, 23 May 2011 16:12:13 +0200
Message-ID: <BANLkTi=GtYtYsyYZ814dU0aMM+tRKDXeKw@mail.gmail.com>
To: www-multimodal@w3.org

Hallo,

Other specs often use tables to outline child elements and attributes. I
would recommend using a table, too.
One column of the table could define if a property is mandatory or optional.
Also by using joint cells
mutually exclusive properties could be outlined well.

Regards,
Jakob.

Notes:

Related e-mails:

ISSUE-195 - qualified vs unqualified attributes

Tracker (W3C Member only):

ISSUE-195

Opened:

2011-05-03

Last Updated:

2011-05-16

State:

closed

Description:

From: Jakob Sachse <jakobsa@gmail.com>
Date: Tue, 3 May 2011 17:48:05 +0200
Message-ID: <BANLkTinWBuXUkECHJRqeOrBaY05n67fP-Q@mail.gmail.com>
To: www-multimodal@w3.org

Hi,

I have been rechecking my findings and found another point that i would
like to comment on.

In contrast to what i wrote in my prior mail, not all .xsd files in Appendix
C
have attributeFormDefault and elementFormDefault set.

- mmi.xsd (Appendix C.1)

Neither has elementFormDefault = "qualified" on the schema element
nor form="qualified" on the mmi-element definition set. Since
"unqualified" is the default value all mmi elements are to be used
unqualified only.
This, as far as I know, makes most of the examples invalid as they
use the mmi element in a qualified way.

- mmi-datatypes.xsd (Appendix C.2)

Does not have attributeFormDefault nor elementFormDefault set. Which makes
it being set to the default value "unqualified". Types and Attributes
defined in this
xsd 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 should
look into
this. One thing I had to find out (while investigating my findings) was that
elementFormDefault and attributeFormDefault won't get inherited by child
documents
included 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 +0200
Message-ID: <BANLkTimos=YTHD99xZycxN23U_DwMw2mig@mail.gmail.com>
To: www-multimodal@w3.org
Cc: 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 local
elements.
Global elements as mmi always have to be used qualified, regardless of the
value of
elementFormDefault. Thats why the examples given are valid regarding this
point.

I am sorry for the confusion.

Regards,
Jakob.

STATUS=CLARIFICATION
ACCEPTANCE=EXPLICIT

Notes:

Related e-mails: