- From: Hans Wennborg <hwennborg@google.com>
- Date: Wed, 16 May 2012 16:02:41 +0100
- 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 SpeechRecognitionErrorEvent)? Thanks, Hans
Received on Wednesday, 16 May 2012 15:04:09 UTC