Re: [speechXG] parameter setting for the recognition object

I believe that the browser event loop would take care of this. The
browser should defer telling the speech recognizer about the changed
parameters until it finishes processing the current JavaScript
invocation. For example, I think that this is how changing DOM
attributes of visible elements is done without intermediate states
being rendered.

/Bjorn

On Thu, Jul 28, 2011 at 11:57 AM, Young, Milan <Milan.Young@nuance.com> wrote:
> Bjorn, are you arguing that we don't need to solve this problem, or that
> something about the JavaScript flow control implicitly handles the
> issue?
>
> Thanks
>
>
> -----Original Message-----
> From: public-xg-htmlspeech-request@w3.org
> [mailto:public-xg-htmlspeech-request@w3.org] On Behalf Of Bjorn Bringert
> Sent: Thursday, July 28, 2011 11:23 AM
> To: Deborah Dahl
> Cc: HTML Speech XG
> Subject: Re: [speechXG] parameter setting for the recognition object
>
> My suggestion towards the end was to not have any special API support
> for atomically setting multiple parameters. That is, neither a map nor
> updateParameters(). This would match how setting parameters on DOM
> elements works.
>
> /Bjorn
>
> On Thu, Jul 28, 2011 at 11:17 AM, Deborah Dahl
> <dahl@conversational-technologies.com> wrote:
>> On today's call we talked about the general process of setting
> parameters
>> for recognition. In my proposal
>>
> (http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jun/0086.h
> tml)
>> I had suggested that we might want to pick a couple of very frequently
> set
>> parameters (e.g. grammar and language) and allow them to be set
> directly as
>> parameters of the "start recognition" method, as a type of convenience
>> syntax. We agreed during the call that this was not necessary, and
> agreed
>> that all the parameters should be explicitly set on the recognition
> object,
>> e.g. something like "recognizer.endpointdetection(true)". However,
> this
>> raised the question of what happens when parameters are set while a
>> recognition is in progress. Bjorn's suggestion was to have an
>> "updateParameters" method that is invoked after the parameter setting
>> function is called to actually cause the parameters to take effect on
> the
>> recognition object. Another option is to distinguish parameters that
> take
>> effect immediately, like changing the grammar, from parameters that
> take
>> effect only when the next recognition occurs (like maxnbest).
>> We also discussed setting multiple parameters and whether there should
> be a
>> way to set several parameters in one call, as in this example that
> Olli
>> typed into irc: setParameters({ param1: value, param2: value2}). This
> might
>> be convenient, but Bjorn pointed out that it isn't done in any HTML
> API's.
>> I'm hoping to update my proposal and sent it out again next week, so
> any
>> discussion on the list in the meantime would be helpful. If anyone who
> was
>> on the call today has anything to add to this summary, that would be
>> helpful, too.
>> Debbie
>>
>>
>>
>
>
>
> --
> Bjorn Bringert
> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
> Palace Road, London, SW1W 9TQ
> Registered in England Number: 3977902
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Thursday, 28 July 2011 19:11:07 UTC