Re: Speech API Community Group

To elaborate on Milan's assertion, imagine a large company (airline, 
bank, etc.) that already has a significant investment in IVR (thousands 
of ports of ASR-enabled VXML).  They are eager to add web access as an 
option, but want to make sure  that the recognition is done by their 
existing servers, which they have spent years and $$ tuning.  They are 
not going to trust their customer's experience (or financial data) to 
whatever speech engine he happens to have configured on his browser.  
Hence the need for the application author to specify a specific network 
speech service as part of the application.  (That doesn't  mean that the 
developer _must_ specify such a service, just that he _can_ if his 
application calls for it.)

- Jim

On 4/3/2012 2:59 PM, Young, Milan wrote:
>
> It matters to the application author that they can select a service 
> that works best for them.  Relying on browser or OS configurations 
> would not suffice for real-world speech applications.
>
> I don't see how we can properly specify the process of selection 
> without the mention of network services.  Hence the language request.
>
> *From:*Jerry Carter [mailto:jerry@jerrycarter.org]
> *Sent:* Tuesday, April 03, 2012 11:46 AM
> *To:* Young, Milan
> *Cc:* Glen Shires; public-xg-htmlspeech@w3.org; public-webapps@w3.org
> *Subject:* Re: Speech API Community Group
>
> On Apr 3, 2012, at 11:48 AM, Young, Milan wrote:
>
>
>
> The proposal mentions that the specification of a network speech 
> protocol is out of scope. This makes sense given that protocols are 
> the domain of the IETF.
>
> But I'd like to confirm that the use of network speech services are in 
> scope for this CG.  Would you mind amending the proposal to make this 
> explicit?
>
> I don't see why any such declaration is necessary.  From the 
> perspective of the application author or of the application user, it 
> matters very little where the speech-to-text operation occurs so long 
> as the result is delivered promptly.  There is no reason that local, 
> network-based, or hybrid solutions would be unable to provide adequate 
> performance.  I believe the current language in the proposal is 
> appropriate.
>
> -=- Jerry
>