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

Hello Hans,

Both VoiceXML and the HTML Speech recommendation leverage aliases as a means of minimizing syntax.  Aside from the IDL representation, I personally don't view this as overly complicating the spec.  And as far as implementation, it's just a few lines of code for the UAs.

SpeechRecognitionErrorEvent is also a bit long for my tastes.  I had originally proposed SpeechRecognitonError, but if you feel the Event suffix adds value, I'm fine with that.

Thanks

-----Original Message-----
From: Hans Wennborg [mailto:hwennborg@google.com] 
Sent: Wednesday, May 16, 2012 8:03 AM
To: Young, Milan
Cc: Satish S; public-speech-api@w3.org
Subject: Re: Flatter structure for SpeechRecognitionResult (was: "Speech API: first editor's draft posted")

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 22:36:01 UTC