Re: SpeechRecognitionError use of enum instead of const

I'm assuming this is for all enums throughout the spec?

Also, I haven't been commenting on the speech reco part of the spec, but
I'm a little concerned about the "other" error enum. Is there a need to
actually have that in the spec? I think it's assumed that a well-written
client would have to be prepared for errors outside the spec (for future
expansion), and if a new error is needed later I think it'd make far more
sense for a user agent to return a specific error code with a vendor prefix
("webkit-user-cancelled") rather than "other".

- Dominic

On Mon, Oct 8, 2012 at 8:36 AM, Hans Wennborg <hwennborg@google.com> wrote:

> On Fri, Oct 5, 2012 at 10:34 PM, Glen Shires <gshires@google.com> wrote:
> > My understanding is that the use of const is discouraged in favor of
> strings
> > or enumerations: http://dev.w3.org/2006/webapi/WebIDL/#idl-constants
> >
> > Based on this, I propose changing our SpeechRecognitionError from
> "const" to
> > the following "enum" (no change to the corresponding definitions). If
> > there's no disagreement, I'll update the spec with this on Monday.
> >
> >     interface SpeechRecognitionError : Event {
> >         enum ErrorCode {
> >           "other",
> >           "no-speech",
> >           "aborted",
> >           "audio-capture",
> >           "network",
> >           "not-allowed",
> >           "service-not-allowed",
> >           "bad-grammar",
> >           "language-not-supported"
> >         };
> >
> >         readonly attribute ErrorCode error;
> >         readonly attribute DOMString message;
> >     };
>
> Sounds good to me.
>
> Thanks,
> Hans
>
>