W3C home > Mailing lists > Public > public-speech-api@w3.org > March 2013

Re: Poor error events in SpeechSynthesis API

From: Glen Shires <gshires@google.com>
Date: Thu, 7 Mar 2013 10:30:47 -0800
Message-ID: <CAEE5bciQfo7=d9mwEQZU_zKJK04UxnnWYw8AC3ucQjT_n5mD3A@mail.gmail.com>
To: Eitan Isaacson <eisaacson@mozilla.com>
Cc: "public-speech-api@w3.org" <public-speech-api@w3.org>
I believe it's most useful to define a set of enums (similar to
SpeechRecognitionError ErrorCode), so that JavaScript can programmatically
handle different errors. Thus, one criteria for evaluating which enums
errors should be included is to understand understand for which conditions
a script might want to take specific/different actions (examples: retry
with a different voice, or inform the user that audio output is not
available or configured properly.)

If we also choose to add a message attribute, it should be "primarily
intended for debugging and developers should not use it directly in their
application user interface", similar to reco:
https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html#dfn-message
So one criteria is: do we envision that there will be messages that
will
provide more info beyond the enums we define.

I propose we first reach consensus on whether we need "message" string in
addition to "error" enum code. Then let's decide whether to re-use
SpeechSynthesisEvent or define a new SpeechSynthesisErrorEvent.

Glen Shires


On Thu, Mar 7, 2013 at 10:26 AM, Eitan Isaacson <eisaacson@mozilla.com>wrote:

> This all looks great, a quick tangent below..
>
> On 03/07/2013 10:11 AM, Dominic Mazzoni wrote:
> >           "language-not-supported"  // unsure if necessary, since
> > should use getVoices()
>
> The way I understand the voice matching, an API consumer could simply
> send an utterance to speak with a language specified without doing
> getVoices() before, and trusting the user agent to find the best match.
> For example:
>
> The app specifies en-GB in an utterance. First the UA searches for an
> en-GB default voice, if that is not satisfied, it searches for an en-GB
> non-default voice, if that is not satisfied, it searches for the first
> "en" prefixed default voice, if no luck it searches for an "en" prefixed
> non-default voice. So hypothetically, the matching voice might be en-US.
> If there are no English voices, then a "language-not-supported" error
> could be raised because there is no voice that could synthesis the
> utterance.
>
>
Received on Thursday, 7 March 2013 18:31:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 March 2013 18:31:57 GMT