RE: Proposal categories

I have a couple of comments on the first category, "specify simple APIs for speech recognition and speech synthesis using
speech service implementations provided by the browser or platform".
1. Wouldn't a better statement be just "Specify simple APIs for speech recognition and speech synthesis that address as many of our prioritized requirements as possible"? I think simplicity and addressing our requirements is more important to us than exactly where the services come from. 
2. It's also worth pointing out that a proposal that's "simple" to one community isn't necessarily "simple" to everyone. Let me make this more concrete by defining 4 communities that have an interest in simplicity from their own perspectives.
a. end users
b. developers
c. platform implementers
d. standards groups

A proposal might be simple for platform developers, but create difficulties for end users. For example, the UI becomes more complex for users if they have to push a button to initiate the start and end of speech, but that might make implementation easier. As another example, a specification that leaves key areas as "implementation-specific" is easier for the standards group, but not so great for developers. When we talk about what's simple, I think we have to keep these different communities in mind, and in roughly this order of priority. 

> -----Original Message-----
> From: public-xg-htmlspeech-request@w3.org [mailto:public-xg-htmlspeech-
> request@w3.org] On Behalf Of Robert Brown
> Sent: Tuesday, February 01, 2011 10:48 PM
> To: Bjorn Bringert; public-xg-htmlspeech@w3.org
> Subject: RE: Proposal categories
> 
> >> Is anyone working a proposal that doesn't fit neatly into exactly one of
> these categories?
> 
> Yes, ours won't :-)  At least, not "neatly".
> 
> We’ll submit a proposal at the end of Feb.
> 
> I think any proposals should be mapped back to the questionnaire results
> and recommendations Dan posted last Tuesday.
> 
> #1 depending on how it's read, seems to be at odds with the voting on
> requirements like FPR12 and FPR8.
> #2 is sound in principle and should be pursued, but feels like a longer-term
> thing that won't yield results any time soon.  We should also consider what
> can be done in a v.1 - we may not hit all the scenarios, but if we can hit a
> decent subset, that's an awful lot better than nothing.
> #3 Is attractive, but I'm wary.  TTS is generally a UI element that's used to
> interact with content, whereas music and video are generally content around
> which a UI is built.  The different use cases make me skeptical: just because
> TTS happens to supply audio doesn't mean it has the same semantics as
> music tracks or videos.
> 
> /Rob
> 
> 
> -----Original Message-----
> From: public-xg-htmlspeech-request@w3.org [mailto:public-xg-htmlspeech-
> request@w3.org] On Behalf Of Bjorn Bringert
> Sent: Monday, January 31, 2011 1:14 PM
> To: public-xg-htmlspeech@w3.org
> Subject: Proposal categories
> 
> Here are the things that I would personally like to see proposals for, in my
> priority order (high to low):
> 
> 1. Specify simple APIs for speech recognition and speech synthesis using
> speech service implementations provided by the browser or platform
> ("default speech services" in our requirements terminology).
> 
> 2. Work with other groups (e.g. RTC-Web) to add a general mechanism for
> audio streaming with the features needed for speech recognition.
> 
> 3. Enhance existing and proposed audio playback APIs (such as HTML <audio>
> and the proposed JS audio APIs) to work for TTS from web-app specified
> network speech synthesizers.
> 
> What do you think of this division? Who is planning to submit proposals in
> what categories? Is anyone working a proposal that doesn't fit neatly into
> exactly one of these categories?
> 
> --
> Bjorn Bringert
> Google UK Limited, Registered Office: Belgrave House, 76 Buckingham Palace
> Road, London, SW1W 9TQ Registered in England Number: 3977902
>

Received on Wednesday, 2 February 2011 14:41:06 UTC