RE: Speech API Community Group

The problem is that the community group has an ambiguous “charter”, and at least some folks would like this clarified before joining.  Being that Speech-XG and Webapps are the two most relevant lists, I don’t know where else the discussion would take place.

I believe that all of this could be cleared up by a simple statement from the CG chair (Glen Shires) that FPR7 and FPR12 are in scope.  There is “STRONG” interest in this domain and an editor has already volunteered (Jim Barnett).  Seems like a simple decision.

Thanks


From: Charles Pritchard [mailto:chuck@jumis.com]
Sent: Tuesday, April 03, 2012 1:29 PM
To: Michael Bodell
Cc: Jerry Carter; Raj (Openstream); Young, Milan; Jim; Glen Shires; public-xg-htmlspeech@w3.org; public-webapps@w3.org
Subject: Re: Speech API Community Group

I'd like to encourage everyone interested in the Speech API to join the mailing list:
http://lists.w3.org/Archives/Public/public-speech-api/


For those interested in more hands-on interaction, there's the CG:
http://www.w3.org/community/speech-api/


For some archived mailing list discussion, browse the old XG list:
http://lists.w3.org/Archives/Public/public-xg-htmlspeech/


It seems like we can move this chatter over to public-speech-api and off of the webapps list.

-Charles


On 4/3/2012 1:08 PM, Michael Bodell wrote:
A little bit of historical context and resource references might be helpful for some on the email thread.

While this is still an early stage for a community group, if one will happen, it actually isn’t early for the community as a group to talk about this.  In many ways we’ve already done the initial incubation and community discussion and investigation for this space in the HTML Speech XG.  This lead to the XG’s use case and requirements document:
http://www.w3.org/2005/Incubator/htmlspeech/live/requirements.html


which were then refined to a prioritized requirement list after soliciting community input:
http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/#prioritized


As I read it, Milan and Jim and Raj’s requirements discussed are part of FPR7 [Web apps should be able to request speech service different from default] and FPR12 [Speech services that can be specified by web apps must include network speech services], both of which were voted to have “Strong Interest” by the community.

Further work from these requirements led to the community coming up with a proposal, which is ready now to be taken to a standards track process, that was published in the XG final report:
http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/


Hopefully we can all properly leverage the work the community has already done.

Michael Bodell
Co-chair HTML Speech XG


From: Jerry Carter [mailto:jerry@jerrycarter.org]
Sent: Tuesday, April 03, 2012 12:50 PM
To: Raj (Openstream); Milan Young; Jim
Cc: Glen Shires; public-xg-htmlspeech@w3.org<mailto:public-xg-htmlspeech@w3.org>; public-webapps@w3.org<mailto:public-webapps@w3.org>
Subject: Re: Speech API Community Group


We can discuss this in terms of generalities without any resolution, so let me offer two more concrete use cases:

My friend Jóse is working on a personal site to track teams and player statistics at the Brazil 2014 World Cup.  He recognizes that the browser will define a default language through the HTTP Accept-Language header, but knows that speakers may code switch in their requests (e.g. Spanish + English or Portuguese + English or ) or be better served by using native pronunciations (Jesus = /heːzus/ vs. /ˈdʒiːzəs/).  Hence, he requires a resource that can provide support for Spanish, English, and Portuguese and that can also support multiple simultaneous languages.

These are two solid requirements.  A browser encountering the page might (1) be able to satisfy these requirements, (2) require user permission before accessing such a resource, or (3) be unable to meet the request.

My colleague Jim has another application for which hundreds of hours have been invested to optimize the performance for a specify recognition resource.  Security considerations further restrict the physical location of conforming resources.  His page requires a very specific resource.

These are two solid requirements.  A browser encountering the page might (1) be able to satisfy these requirements, (2) require user permission before accessing such a resource, or (3) be unable to meet the request.

There are indeed commercial requirements around the capabilities of resources.  We are in full agreement.  It is important to be able to list requirements for conforming resources and to ensure that the browser is enforcing those requirements.  That stated, the application author does no care where such a conforming resource resides so long as it is available to the targeted user population.  The user does not care where the resource resides so long as it works well and does not cost too much to use.

The trick within a Speech JavaScript API is to define what characteristics may be specified for resource selection or, alternatively, to determine that such definition is external to the immediate API: for instance,  there might be a separate spec which is referenced by the Speech JavaScript API.  It is too early to tell what direction the group might go.  It is already clear that there are strong opinions as to what criteria may be necessary for resource selection.  Refusing to participate unless one's specific criteria are addressed strikes me as quite inappropriate at this early stage.

-=- Jerry



On Apr 3, 2012, at 3:15 PM, Raj (Openstream) wrote:




Perhaps true for users of the applicaitons. But, Authors would need Resource-specification(location),
hence clearly specifying how network/local services can be used ( even if protocols are out of scope)
, outside of browser-defaults will be of interest to many including Openstream.

Raj



On Tue, 3 Apr 2012 14:45:45 -0400
Jerry Carter <jerry@jerrycarter.org<mailto:jerry@jerrycarter.org>> wrote:


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

--
NOTICE TO RECIPIENT:  THIS E-MAIL IS  MEANT FOR ONLY THE INTENDED RECIPIENT OF THE TRANSMISSION, AND MAY BE A COMMUNICATION PRIVILEGED BY LAW.  IF YOU RECEIVED THIS E-MAIL IN ERROR, ANY REVIEW, USE, DISSEMINATION, DISTRIBUTION, OR COPYING OF THIS E-MAIL IS STRICTLY PROHIBITED.  PLEASE NOTIFY US IMMEDIATELY OF THE ERROR BY RETURN E-MAIL AND PLEASE DELETE THIS MESSAGE FROM YOUR SYSTEM. THANK YOU IN ADVANCE FOR YOUR COOPERATION. Reply to : legal@openstream.com<mailto:legal@openstream.com>