A few high level thoughts about the web api sections 3 and 4.

Thanks to Michael for the latest
draft<http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Sep/att-0008/speechwepapi.html>last
week, I was reading through it and looking at other web apis which may
have similar structure. Below are a few comments which came out of it
related to sections we have already covered in the conf calls.

In section 3.2:
- It seems that the "new ObjectName()" model is preferred generally over a
".createObjectName()" method. I see this in the File
API<http://www.w3.org/TR/FileAPI> and
others. So
  createSpeechInputRequest() could become a 'SpeechInputRequest' object that
can be created in JS
  createSpeechOutputRequest() could become a 'SpeechOutputRequest' object
that can be created in JS

In section 3.1:
- Can we drop the 'service' prefix from the attributes and have them as just
'type', 'uri' and 'name'? This interface isn't going to be implemented by
any existing browser object (like window or navigator) so these attributes
wouldn't be clashing with others.
- There is some disconnect between the IDL and the writeup below about the
TTS and ASR values. If they are really bitfields the IDL should mention the
values as 1 and 2.

In section 4:
- Instead of SpeechServiceQuery being a method of the window object, can we
have 'navigator.speech' be the top level object that implements this
interface (similar to 'navigator.geolocation' in the Geolocation
API<http://dev.w3.org/geo/api/spec-source.html>and others)? This
allows web apps to check for 'if (navigator.speech)' and
decide if speech APIs are supported. It will also be cleaner if we add new
methods/attributes in future.
- This 'navigator.speech' top level obj can also have a '.services'
attribute which contains a list of all the SpeechService objects. An app
which doesn't want to query capabilities but just pick a service based on
uri or name can do so with this (e.g. picking the default)
- When querying for a speech service, we probably don't need to filter by
URI & service type because that is already available as an attribute (with
the above navigator.speech.services list). This allows us to use the speech
service query for only capabilities that require a round trip to the service
and may take time.
- I think we should avoid filtering by codec because it is something which
is typically negotiated by the UA and service based on various conditions.
The same UA and service could use different codecs in different environments
so the web app should ideally be agnostic to it.
- The timeout value in QueryOptions doesn't seem to have a precedence in
other web apis. I suggest that we leave it to the UA to have a built-in
timeout similar to every other network connection timeout in the UA. If we
agree, QueryOptions can be replaced with just Criteria.

Updated IDL fragment:

// Can be created in JS by 'new Criteria()'
[Constructor]
interface Criteria {
    attribute sequence<DOMString> languages;
    attribute sequence<DOMString> grammars;
}

// This replaces SpeechServiceQuery and is implemented by navigator.speech
interface NavigatorSpeech {
    // This replaces the 'SpeechServiceQuery.speechServiceQuery()' method
    void getMatchingServices(Criteria criteria,
                             in speechSerivceCallback serviceCB,
                             optional speechServiceErrorCallback);

    readonly attribute sequence<SpeechService> services;
}

[Callback=FunctionOnly, NoInterfaceObject]
interface speechServiceCallback {
    void handleEvent(in sequence<SpeechService> speechServices);
};


Cheers
Satish