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

Re: Request to change WebSpeech to remove usage of SpeechSynthesisVoiceList

From: ᛏᚮᛘᛘᚤ <tommyw@google.com>
Date: Tue, 12 Feb 2013 09:27:35 +0100
Message-ID: <CALLKCfOSFQg7NQJTFdkS1CKFexL-JQLrvnk+kOqtaXAp4Bj27A@mail.gmail.com>
To: Glen Shires <gshires@google.com>
Cc: Hans Wennborg <hwennborg@google.com>, Chris Fleizach <cfleizach@apple.com>, "public-speech-api@w3.org" <public-speech-api@w3.org>, James Craig <jcraig@apple.com>
The first option is not valid, that's what sequence<> is used for.  The
options are either to use the old fake list or change the attribute result
to a function getResults() which aligns the API with other new APIs like
WebRTC.

Btw, its pretty easy to write JS that are compatible with both a function
and an attribute; first add compability with the old:

if (!SpeechRecognitionEvent.prototype.getResults) {
    SpeechRecognitionEvent.prototype.getResults = function() {
        return this.results;
    }
}

and then change the usage to the new function.




On Mon, Feb 11, 2013 at 6:50 PM, Glen Shires <gshires@google.com> wrote:

> Tommy discovered that WebIDL forbids sequence<xx> for attributes, it's
> only for function results:
> http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence
>
> So I see three options for SpeechRecognitionEvent.results:
>
> 1. Define it as an array instead of a sequence.  The change to the IDL
> would be:
>
>   Section 5.1 IDL:
>     "readonly attribute sequence<SpeechRecognitionResult> results;"
>   should be
>     "readonly attribute SpeechRecognitionResult[] results"
>
>
> 2. Revert back to the original IDL in the spec. (That is, strikeout errata
> E04.) [1]
>
>
> 3. Change it from a readonly attribute to a function. The change to the
> IDL would be:
>
>   Section 5.1 IDL:
>     "readonly attribute sequence<SpeechRecognitionResult> results;"
>   should be
>     "sequence<SpeechRecognitionResult> getResults()"
>
>
>
> I prefer the first option. Like sequence<xx> an array remains compatible
> with the result[i] syntax (so no change for JavaScript applications using
> this syntax), and doesn't support the result.item(i) syntax.
>
> The second option would be OK too.
>
> I dislike the third option because the syntax for JavaScript applications
> changes. Also, because this would add a function call
> to SpeechRecognitionEvent, which currently holds only attributes, so it
> would be inconsistent and "odd" in my opinion.
>
> What are your thoughts?
>
> Also, any additional thoughts on SpeechGrammarList?
>
> Glen Shires
>
>
> [1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi-errata.html
>
>
>
> On Wed, Feb 6, 2013 at 7:01 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <
> tommyw@google.com> wrote:
>
>> FYI the "Media Capture and Streams" spec did this with MediaStream and
>> MediaStreamtrackList and it turned out OK imho.
>>
>>
>> On Tue, Feb 5, 2013 at 7:56 AM, Glen Shires <gshires@google.com> wrote:
>>
>>> One option for a similar change to SpeechGrammarList is to move its
>>> methods to its parent as shown below.
>>>
>>> Remove SpeechRecognitionResultList and change:
>>>
>>> interface SpeechRecognition : EventTarget {
>>>         attribute sequence<SpeechGrammar> grammars;
>>>
>>>         void addGrammarFromURI(in DOMString src, optional float weight);
>>>         void addGrammarFromString(in DOMString string, optional float
>>> weight);
>>>         ...
>>> }
>>>
>>>
>>> However, I prefer the current syntax because the encapsulation of
>>> methods is cleaner.  Any thoughts or other proposals?
>>>
>>> /Glen Shires
>>>
>>>
>>> On Mon, Feb 4, 2013 at 10:36 PM, Glen Shires <gshires@google.com> wrote:
>>>
>>>> I've updated the errata with the above change:
>>>> https://dvcs.w3.org/hg/speech-api/rev/58e2afd5d423
>>>>
>>>> As always, the current errata is at:
>>>> http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi-errata.html
>>>>
>>>>
>>>> Should we consider a similar change to SpeechGrammarList? (It's not as
>>>> straight-forward because the object has methods.) Any proposals?
>>>>
>>>> /Glen Shires
>>>>
>>>>
>>>> On Tue, Jan 22, 2013 at 3:43 PM, Glen Shires <gshires@google.com>wrote:
>>>>
>>>>> I agree, this makes for a cleaner, more modern IDL and doesn't affect
>>>>> the JavaScript syntax.  So unless there is disagreement, I will add the
>>>>> following to the errata on Feb 4.
>>>>>
>>>>> Remove SpeechSynthesisVoiceList and change:
>>>>>
>>>>> interface SpeechSynthesis {
>>>>>         sequence<SpeechSynthesisVoice> getVoices();
>>>>> };
>>>>>
>>>>> Remove SpeechRecognitionResultList and change:
>>>>>
>>>>> interface SpeechRecognitionEvent : Event {
>>>>>         readonly attribute sequence<SpeechRecognitionResult> results;
>>>>> };
>>>>>
>>>>>
>>>>>
>>>>> Also, we might consider a similar change to SpeechGrammarList, but
>>>>> it's not as straight-forward because this object has methods. Any proposals?
>>>>>
>>>>> Glen
>>>>>
>>>>>
>>>>> On Thu, Jan 17, 2013 at 12:34 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <
>>>>> tommyw@google.com> wrote:
>>>>>
>>>>>> Yeah, I am doing exactly the same to the WebRTC stuff in WebKit. The
>>>>>> recentish support for sequence<> in WebKit rocks. And the change
>>>>>> wouldn't break anything either.
>>>>>>
>>>>>> /Tommy
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 17, 2013 at 9:27 AM, Hans Wennborg <hwennborg@google.com>
>>>>>> wrote:
>>>>>> > On Wed, Jan 16, 2013 at 9:19 PM, Chris Fleizach <
>>>>>> cfleizach@apple.com> wrote:
>>>>>> >> Hi,
>>>>>> >>
>>>>>> >> I think that instead of using the custom SpeechSynthesisVoiceList
>>>>>> object, we can use a normative Javascript array to return the list of voices
>>>>>> >> in getVoices().
>>>>>> >>
>>>>>> >> The IDL change would change from
>>>>>> >>
>>>>>> >> interface SpeechSynthesis {
>>>>>> >>         SpeechSynthesisVoiceList getVoices();
>>>>>> >> };
>>>>>> >>
>>>>>> >> to
>>>>>> >>
>>>>>> >> interface SpeechSynthesis {
>>>>>> >>         sequence<SpeechSynthesisVoice> getVoices();
>>>>>> >> };
>>>>>> >>
>>>>>> >> Then the SpeechSynthesisVoiceList can be removed.
>>>>>> >>
>>>>>> >> Thanks for your consideration
>>>>>> >
>>>>>> > +tommyw
>>>>>> >
>>>>>> > I guess this would apply to the other lists in the spec too? I.e.
>>>>>> > SpeechGrammarList and SpeechRecognitionResultList?
>>>>>> >
>>>>>> > Seems like this would both simplify the spec and implementation a
>>>>>> bit.
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Hans
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Received on Tuesday, 12 February 2013 08:28:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 February 2013 08:28:05 GMT