RE: Flatter structure for SpeechRecognitionResult

Hello Olli,

You are on the editor list, so I must be walking into a trap :).  I was referring to the final report that was recommended by HTML Speech XG.  Calling this the HTML Speech Recommendation was a mistake, but all I was trying to show was that there is some precedent.

In any case, section 7.1.4 of this document contains a few examples of the JS aliases I was recommending: http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/ 

 Thanks

-----Original Message-----
From: bugs@pettay.fi [mailto:bugs@pettay.fi] 
Sent: Thursday, May 17, 2012 2:18 AM
To: Young, Milan
Cc: Hans Wennborg; Satish S; public-speech-api@w3.org
Subject: Re: Flatter structure for SpeechRecognitionResult

On 05/17/2012 01:35 AM, Young, Milan wrote:
> Hello Hans,
>
> Both VoiceXML and the HTML Speech recommendation

What HTML Speech recommendation?



(Hmm, why am I getting these emails to this email address)


-Olli


  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 Thursday, 17 May 2012 15:59:14 UTC