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

Re: Flatter structure for SpeechRecognitionResult (was: "Speech API: first editor's draft posted")

From: Hans Wennborg <hwennborg@google.com>
Date: Wed, 16 May 2012 16:02:41 +0100
Message-ID: <CAB8jPhf=kbKkb8xKteORjFv-ntzKXQc1fXxwvkOj7bvh88QB_A@mail.gmail.com>
To: "Young, Milan" <Milan.Young@nuance.com>
Cc: Satish S <satish@google.com>, "public-speech-api@w3.org" <public-speech-api@w3.org>
On Thu, Apr 26, 2012 at 9:00 PM, Young, Milan <Milan.Young@nuance.com> wrote:
> 1) Flatter structure:  My original suggestion was to eliminate the 'result' object in the event.  For example, event.result.item.transcript becomes event.item.transcript (in your example you missed the 'item' token BTW).  But maybe a better idea would be to alias item[0] to the top level in the result.  So event.result.item.transcript would become event.result.transcript.  I'm not sure if IDL is capable of representing the idea of an alais (double inheritance?), but I think it would make sense to developers.  For reference, VoiceXML uses this same pattern.

Hmm, yes I can see that "e.result.item(0).transcript" could be a bit
cumbersome for the common case of just getting the text of the first
alternative. At the same time, I don't want to complicate the API :/

> 2) I find it ugly that the event would contain both a success and error path when their usage is mutually exclusive.  In languages that I'm familiar with, such notifications would be thrown with different events.  I don't have much DOM experience, but I've seen something similar with onError()/onSuccess() callbacks and the pattern seems reasonable.  But being that you have more experience with DOM, I'm open to your suggestions.  I didn't quite follow what you were saying below, so perhaps you could rephrase.

I agree. I would be happy to have the error split out of SpeechRecognitionEvent.

How about we remove 'error' from SpeechRecognitionEvent, and make the
SpeechRecognitionError an Event (possibly renaming it to

Received on Wednesday, 16 May 2012 15:04:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:26 UTC