W3C home > Mailing lists > Public > public-speech-api@w3.org > June 2012

RE: Default value of SpeechRecognition.grammars

From: Young, Milan <Milan.Young@nuance.com>
Date: Fri, 22 Jun 2012 17:34:00 +0000
To: Satish S <satish@google.com>
CC: Jerry Carter <jerry@jerrycarter.org>, Hans Wennborg <hwennborg@google.com>, "public-speech-api@w3.org" <public-speech-api@w3.org>
Message-ID: <B236B24082A4094A85003E8FFB8DDC3C1A4757A2@SOM-EXCH04.nuance.com>
Defaults should be implemented as though the web author specified it themselves.  For example, if the default for parameter 'foo' is 'bar', then a developer should be able to set 'foo' to 'bar' and expect no change.

It sounds like your proposal for a grammar default does not follow these rules.  And author relying on defaults would not get BAD_GRAMMAR events, whereas if they set it explicitly they would.  I can't support that.

I fully support specifying a minimal set of builtin grammars for common operations like 'dictation', 'contacts', 'apps' and 'search'.  Implementations would be free to extend this set with types like 'builtin:default', but I don't think these aggregate grammars should be explicitly endorsed by the spec.

In any case, the spec must be clear that a grammar must mean essentially the same thing regardless of connectivity or other transient situations.   Sure we'll allow "today" and other context-sensitive utterances to mean slightly different things in different situations, but something as significant as suddenly not supporting dictation would not be allowed.  That must constitute an unavailable grammar allowing the application layer to adjust.

Can we agree on that?

From: Satish S [mailto:satish@google.com]
Sent: Friday, June 22, 2012 1:45 AM
To: Young, Milan
Cc: Jerry Carter; Hans Wennborg; public-speech-api@w3.org
Subject: Re: Default value of SpeechRecognition.grammars

I think we both agree it is useful to fire events when user specified grammars can't be loaded or such cases (e.g. the BAD_GRAMMAR error code in onerror event). So my proposal is that a web application that really needs to know when grammars come in and out of scope should use custom grammars and select an alternate grammar if one fails.

Re: the default grammar's URI - Is there agreement on using "builtin:default" ?


On Fri, Jun 22, 2012 at 1:30 AM, Young, Milan <Milan.Young@nuance.com<mailto:Milan.Young@nuance.com>> wrote:
I can't support an API that doesn't allow the application layer to know when the underlying grammars come in and out of scope.  I put forward a solution that you didn't like.  Do you have an alternative to suggest?

From: Satish S [mailto:satish@google.com<mailto:satish@google.com>]
Sent: Thursday, June 21, 2012 4:27 PM

To: Young, Milan
Cc: Jerry Carter; Hans Wennborg; public-speech-api@w3.org<mailto:public-speech-api@w3.org>
Subject: Re: Default value of SpeechRecognition.grammars

*       The application layer is given control over which recognizers are running
Sounds like this is the same as the serviceURI attribute.

[Milan] The current service URI attribute only permits a single recognizer.  That recognizer could *internally* be a compound recognizer, but for this solution to work, the application would need to invoke the recognizers explicitly.  For example, invoke the local recognizer for contacts/appointments/apps, and a remote recognizer for dictation or websearch.

This seems unrelated to the grammars attribute we are discussing here. I'm also not sure if you are asking for supporting multiple recognizers in one SpeechRecognition session or if you are specifically interested in local recognizers.. the former would complicate the API and I prefer we continue addressing the single recognizer case, and the latter seems out of scope as it should be transparently handled by the UA.

Perhaps this can be spun off into a separate thread if it needs more discussion.

*       Each recognizer publishes a single default grammar

*       If the default grammar is not available in its entirety, the recognizer/UA must generate an error.
I expect the recognizer/UA to return an error if it can't recognize for any reason, including network issues or lack of access to other resources. SpeechRecognition.onerror<http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-onerror> is the event raised in that case. Perhaps what you are looking for is to add an error code here such as RECOGNIZER_ERROR indicating for some reason the recognizer can't function as expected.

[Milan] Glad we are in agreement.  I just want to make clear in the spec that a recognizer cannot automatically change its default grammar in response to an error condition (eg remove dictation).  If you are OK with this, I will suggest text.

I think it is out of scope for the web speech API to place conditions on how a recognizer should and should not select grammars or other internal details. In many cases the recognizer may be provided by the platform and can't be changed by the UA.

Please don't forget about my other request:

*       The default grammar must be addressable in URI format should the developer want to explicitly invoke the default.  For example: builtin:dictation and builtin:contacts.
A URI like builtin:default seems appropriate here. If the web app needs specific capabilities it should set one of the other builtin URIs such as the ones mentioned above (assuming we define a set of builtin grammars)
Received on Friday, 22 June 2012 17:34:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:27:24 UTC