RE: Overview paragraph

All default recognizers must return the same results/timings with the
same input waveform?  All default synthesizers should return the same
samples on the same input SSML?

 

 

________________________________

From: Raj(Openstream) [mailto:raj@openstream.com] 
Sent: Wednesday, April 20, 2011 12:57 PM
To: Satish S; Patrick Ehlen
Cc: Deborah Dahl; Young, Milan; DRUTA, DAN (ATTSI);
public-xg-htmlspeech@w3.org
Subject: Re: Overview paragraph

 

Yes..I agree with Satish's point...any application that desires to
leverage advanced/specific features

of an ASR, cannot be guaranteed to be portable..within the scope our
spec..and applications

that use the default ( LCD ?) recognizer ( not sure if this is what Dan
D had in mind, by saying

"simple" applications )  should be portable and have consistent user
experience with conforming

browser/clients. 

 

--Raj

	----- Original Message ----- 

	From: Satish S <mailto:satish@google.com>  

	To: Patrick Ehlen <mailto:pehlen@attinteractive.com>  

	Cc: Deborah Dahl <mailto:dahl@conversational-technologies.com>
; Young, Milan <mailto:Milan.Young@nuance.com>  ; DRUTA, DAN (ATTSI)
<mailto:dd5826@att.com>  ; public-xg-htmlspeech@w3.org 

	Sent: Wednesday, April 20, 2011 3:38 PM

	Subject: Re: Overview paragraph

	 

	As an express goal, perhaps we should clearly state that
applications that use the default/built-in recognizer should be portable
across all browsers and speech engines. Beyond that, if the web app
chooses to use a particular engine by specifying a URL it seems ok to
rely on extended/additional capabilities provided by that engine.

	
	Cheers
	Satish
	
	

	On Wed, Apr 20, 2011 at 5:00 PM, Patrick Ehlen
<pehlen@attinteractive.com> wrote:

	Deborah is right that not all speech engines will have the same
capabilities, but we should strive to provide general parameterizations
of the potential capabilities wherever possible. Otherwise engine
providers will need to add their own extensions to the standard, and
development will get fractured across the lines of browser/engine, as we
saw happen with earlier Javascript XML handlers, etc.

	
	On Apr 20, 2011, at 8:27, "Deborah Dahl"
<dahl@conversational-technologies.com> wrote:
	
	> I don't think we can reach the goal of applications being
completely
	> portable across speech engines  because speech engines will
always have
	> different capabilities, and some of these are unlikely to be
in the scope of
	> our API.  For example, engines will handle different
languages, some engines
	> will be able to handle larger grammars, some applications will
make use of
	> proprietary SLM's, and some applications won't be usable
without an engine
	> that has a certain level of accuracy. So  I agree with Milan
that the goal
	> is not to standardize functionality across speech engines. I
think we should
	> just say " provide the user with a consistent experience
across different
	> platforms and devices" and leave it at that.
	>
	>> -----Original Message-----
	>> From: public-xg-htmlspeech-request@w3.org
[mailto:public-xg-htmlspeech-
	>> request@w3.org] On Behalf Of Satish S
	>> Sent: Wednesday, April 20, 2011 5:18 AM
	>> To: Young, Milan
	>> Cc: DRUTA, DAN (ATTSI); public-xg-htmlspeech@w3.org
	>> Subject: Re: Overview paragraph
	>>
	>>    >> provide the user with a consistent experience across
different
	>>    platforms and devices irrespective of the speech engine
used.
	>>
	>>
	>>    This effort is not about standardizing functionality
across speech
	>>    engines.  The goal is speech application portability
across the
	>>    browsers.  Simple applications MAY be portable across
speech engine
	>>    boundaries, but that's not a requirement.
	>>
	>>
	>>
	>> I'd say the API proposal should aim for all applications to
be portable
	> across
	>> speech engines. Starting with "may be portable" doesn't seem
to fit the
	> spirit
	>> of the web. Any extensions for speech engine specific
parameters and
	>> results should be optional.
	>
	>
	>