Re: SpeechRecognitionError use of enum instead of const

I've updated the spec with the that change: specifically: Changed
SpeechRecognitionError to use enum instead of const.
https://dvcs.w3.org/hg/speech-api/rev/e4e3ab962f1d

 As always, the current draft spec is at:
http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html


On Mon, Oct 8, 2012 at 8:42 AM, Dominic Mazzoni <dmazzoni@google.com> wrote:

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