Re: First Draft of the Speech Query web API

- What is the use case for having a single SpeechService interface
that can be ASR and/or TTS? Why not have two simpler interfaces:
SpeechRecognitionService, SpeechSynthesisService? (did we talk about
this at the f2f?)

- Many new HTML APIs don't add methods to the window object. Instead
they provide constructors for the necessary interfaces.

- The function for getting the service needs to be asynchronous, since
it might have to make network requests.

Here's a strawman alternative that addresses the above:

interface SpeechRecognitionServiceSpec {
  attribute DOMString serviceUri;
  attribute sequence<DOMString> supportedLangs;
  // ... other criteria

  // On success, a SpeechRecognitionService is passed to successCallback
  void getService(Function successCallback, Function errorCallback);
}

interface SpeechRecognitionService {
  attribute DOMString serviceUri;
  // ... other info about the service
}

A SpeechRecognitionService can be used to create a SpeechInputRequest,
e.g. by having a SpeechInputRequest constructor that takes a
SpeechRecognitionService.

To make simple things easy, it should also be possible to skip using
these interfaces completely, and just make a SpeechInputRequest with
no service specified, or just a service URI.

The SpeechSynthesisService would be analogous, but with some different
attributes in the spec and service objects.

/Bjorn

On Wed, Jun 29, 2011 at 5:50 PM, DRUTA, DAN (ATTSI) <dd5826@att.com> wrote:
> Team,
>
> Attached is the first attempt at the query API.
> This should allow the developer upon initialization of the speech to deterministically build a user experience that matches the service capabilities returned by the service handle.
> With this approach, developer does not disclose his/her intent (what capabilities he/she wants to use) but rather asks the service to present itself with all the features it supports.
>
> At this point I don't think we know what all those capabilities are and they should be a reflection of the protocol agreements.
>
> This is just to get started and I'm sure some of the attributes and methods will have to be revisited once we understand a bit better the overall API framework.
>
> Thanks,
> Dan
>
>
>
> Thanks,
> Dan
> __________________
> Dan Druta
> AT&T | Service Standards
> m: +1 425 381-3126
> e: dan.druta@att.com<mailto:dan.druta@att.com>
>  [cid:image001.png@01CBC128.5FA40B30]
>
>
>
>



-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Received on Thursday, 30 June 2011 13:32:37 UTC