- From: ᛏᚮᛘᛘᚤ <tommyw@google.com>
- Date: Tue, 12 Feb 2013 09:27:35 +0100
- 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>
- Message-ID: <CALLKCfOSFQg7NQJTFdkS1CKFexL-JQLrvnk+kOqtaXAp4Bj27A@mail.gmail.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 UTC