RE: [dis] Re: FPWD: Discovery & Registration of Multimodal Modality Components: State Handling

Thank you very much for your interest in the Discovery and Registration WD and for your detailed comments. They should be extremely helpful as we begin preparing  the next WD of this spec.
We would also be very grateful for any other comments or suggestions that you might have for improving the document.
Best regards,
Debbie Dahl, MMIWG Chair

-----Original Message-----
From: timeless [] 
Sent: Sunday, July 05, 2015 6:45 PM
Subject: [dis] Re: FPWD: Discovery & Registration of Multimodal Modality Components: State Handling

Disclaimer: this review isn't an endorsement of any technology (beyond the ML described momentarily). It's an exercise in the use of the review-announce ML [1]. As general feedback to the Process, I'm hoping to encourage people to:
a. Run a spell checker (really, it's embarrassing).
b. When publishing a FPWD, use the current version of the Process document [2] unless there's a *really* good reason not to.

> (eg, a session component in the hosting framework )

please don't have whitespace at the beginning/end of `(`/`)`/`[`/`]`...
this includes "don't have a whitespace before `,`/`.`" ...

> The State Manager is also the core support for mediated and passive discovery and ilt [sic] can also be used to trigger active discovery using the push mechanism or to execute some of the tasks on fixed discovery.

> Discovery and Regisration [sic] states for a Modality Component

> In short, whent [sic] the Modality Component is no more able to correctly ensure its task.

> This document is governed by the 14 October 2005 W3C Process Document [3].

For a FPWD, this should really have been published under the 2014 process ....

That document you're referencing [3] says:
>> On 1 August 2014, W3C began a transition away from this document [3]; see the current W3C Process Document [2].

> To the best of our knowledge, there is no standardized way to build a web Application that can dynamically combine and control discovered components by querying a registry build based on the modality states.

offhand: the modality => modality
If I'm wrong, please explain.

> This document covers three needs on Discovery & Registration for this kind of web Application implemented following the Multimodal Architecture Specification [4].

> First we propose to define a new component responsible for the 
> management of the state of the Multimodal System

`Multimodal System` should be a link to something or otherwise somehow defined (there's a definition later in the document, please link to it from all places that precede that table). Note that in [3], it isn't even written as such, merely Multimodal systems -- the only place currently available to a reader without prescience.

This also applies to Modality Component and anything else similarly capitalized and only defined later.

> (e.g. visual, acoustic, haptic, olfactive, gustative) (e.g. voice, 
> gesture, handwriting, biometrics capture, temperature sensing, etc).

`etc.` should be spelled as such, you shouldn't use it here (after `e.g.`).

> For the purpose of this document, a modality is a term that covers the way an idea could be communicated or the manner an action could be performed through a medium.

a modality => modality (?)

(.... a ... is a term ... -- is weird).

> the primary modality is speech and an additional modality can be typically gesture, gaze, sketch, or any combination thereof.

`can be typically` is awkward, typically you'd write `can typically be`.
`an additional ... can ... be ... any combination ...` no, no, no, an additional is singular, a combination is plural. This doesn't make sense.

Here you use the Oxford comma:
> An UpdateNotification event MUST include Source, Target, and RequestID.
Here you don't:
> For example, a multimodal Application can be implemented for use in an integrated way, mobile Devices and cell phones, home appliances, Internet of Things objects, robots, television and home networks, enterprise applications, web applications, "smart" cars or medical devices.

Please consistently use or omit it.

> In both cases the Modality Component depends on the Interaction Manager to begin the interaction cycle by raising an event, originated by an internal command or in reaction to a previous notification sent by a Modality Component (Figure 1).

Please make figure references link to their respective figures...

> The interaction can be started by different Modality Components 
> independently Nevertheless,

I think you're missing a `.` before `Nevertheless`

> to start an interaction the Modality component needs to be already 
> part of the system a to be registered, given that a context represents 
> a single extended interaction with one or more Modality Components.The

and you're missing a space after `.` ...

you're missing a `.` at the end of this list item:
> * To provide a list of the available Modality Components
> * To adapt the frequency of requests according to the overall state of the system.

> In this case the Resources Manager is a support not only for the present state handling but also for an evaluation of the quality of service(QoS) provided by each Modality Component.

I'd expect `Quality of Service (QoS)` note both the capitalization and the space before `(` ...

> On the other hand, the UpdateNotification is proposed:, .

`:, .` eh?

random punctuation at the end of these items:
> to periodically inform the Resource Manager about the state of the 
> Modality Component to help in the decision making process used by the 
> state handler (in the server side, for example)

This is a cursory scan at a fraction of the document. I'm not sure if I'll actually scan the whole document.


Received on Tuesday, 7 July 2015 15:30:40 UTC