W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > September 2011

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 13 Sep 2011 08:50:33 -0700
Message-ID: <4E6F7BC9.3030400@helsinki.fi>
To: Satish S <satish@google.com>
CC: public-xg-htmlspeech@w3.org
On 09/13/2011 04:23 AM, Satish S wrote:
> 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>
(please don't link to obsolote documents ;)
  http://dev.w3.org/2006/webapi/FileAPI/ is more up-to-date)

> 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

This is a very different case than file API.
In this case we want to create request based on some SpeechService.
Actually, this is similar to
var file = document.forms['uploadData']['fileChooser'].files[0];
where you get some object from some other container/creator.

>
> 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.

Makes sense

> - 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.
XMLHttpRequest has timeout


> 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
Received on Tuesday, 13 September 2011 15:51:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 September 2011 15:51:25 GMT