W3C home > Mailing lists > Public > public-speech-api@w3.org > April 2012

Re: Additional parameters to SpeechRecognition (was "Speech API: first editor's draft posted")

From: Hans Wennborg <hwennborg@google.com>
Date: Tue, 24 Apr 2012 16:25:10 +0100
Message-ID: <CAB8jPhdQDK-2cA3yHjhEfJWH_y8nSyfGJV3X0MVkLBxRWSScZQ@mail.gmail.com>
To: Satish S <satish@google.com>
Cc: "public-speech-api@w3.org" <public-speech-api@w3.org>
On Tue, Apr 24, 2012 at 14:52, Satish S <satish@google.com> wrote:
> (Splitting off to a new thread so we can follow discussions easily.
> Please start a new threads for proposed additions/changes)
>> SpeechRecognition
>>  - In addition to the three parameters you have listed, I see the following as necessary:
>>        integer maxNBest;
> I can see speech engines defaulting to a specific number of results
> and the web app can tweak it based on performance characteristics it
> needs. Without this attribute the engine should be asked to always
> give the max number of results and let the web app filter, which seems
> suboptimal.

I agree, I think this would be a good addition.

>>        float confidenceThreshold;
> SpeechRecognitionAlternative.confidence provides the value so the web
> app can filter based on that if it needs to. With that in mind do we
> need this attribute?

Agreed. Also, the absolute confidence values are probably not very
interesting. For example, what does a confidence of 0.5 mean? I see
the confidence values as useful for providing an ordering of the
alternatives, not much else.

>>        integer completeTimeout;
>>        integer incompleteTimeout;
>>        integer maxSpeechTimeout;
> Do you have use cases where these should vary between different web
> apps? I think it would be better to leave it to the UA so all web apps
> have consistent timeouts and user expectation doesn't get affected.

I don't like the idea of having three different timeouts. Couldn't the
web page handle timeouts itself, by calling abort() on the
SpeechRecognition object if it takes too long?

Received on Tuesday, 24 April 2012 15:26:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:27:22 UTC