Re: [agenda] 8 September 2011

Sorry I couldn't attend the call last week as I was on leave. I see in the
minutes that Olli's first point was discussed briefly, about automatic
binding to various types of html elements. But it doesn't look like we had a
satisfactory conclusion.

I am wondering if we really need automatic binding to existing elements or
can <reco> just be a standalone new UI element. The main reason I support a
<reco> element is for user initiated recognition (without automatically
throwing up security prompts on page load). This doesn't require automatic
binding and if the <reco> element was just aimed at getting user consent,
start recognition and return results to the JS event handler that would
support the use case of user initiated recognition.

Cheers
Satish


On Thu, Sep 8, 2011 at 11:03 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

> Few comments.
>
>
> "Some elements are catagorized as recoable elements. These are elements
> that can be associated with a reco element:
>
>    button
>    input (if the type attribute is not in the Hidden state)
>    keygen
>    meter
>    output
>    progress
>    select
>    textarea"
>
> This is not enough, and not precise enough.
> How should we handle contentEditable?
> I'm also pretty sure we don't want to set the
> *value* of <input type="checkbox"> but the state etc.
> Also, why not set the value of <input type="hidden"> ?
> (These are the kind of  problems which make the API inconsistent and
>  why I wouldn't have the automatic value binding to HTML elements.)
>
>
> "The reco element's exact default presentation and behavior, in particular
> what its activation behavior"
> We need to still figure out some permission API.
> User must give permission in some way, and Web app needs to probably
> know about user's decision so that if user decides not to ever give
> permission, web app can hide the UI related to speech handling.
>
>
>
> " might be and what implicit grammars might be defined, if any, is
> unspecified and user agent specific. The activation behavior of a reco
> element for events targetted at interactive content descendants of a reco
> element, and any descendants of those interactive content descendants, MUST
> be to do nothing. When a reco element with a reco control is activated and
> gets a reco result, the default action of the recognition event SHOULD be to
> set the value of the reco control to the top n-best interpretation of the
> recognition (in the case of single recognition) or an appended latest top
> n-best interpretation (in the case of dictation mode with multiple inputs)."
>
> I don't understand the "SHOULD" part. If we want to support automatic
> value binding, UA implementing the API must set the value of reco control,
> if there is one.
>
>
>
>
>
>
> On 09/08/2011 11:48 AM, Michael Bodell wrote:
>
>> A number of folks may be out, but it will be good to get through the
>> rest of the API document on the call.  I've attached a new version of
>> the file that incorporates most of the information from the last Web
>> API call.  Last time we only just started on Section 6.  We should
>> start there and finish the document and then continue the discussion
>> on results formats.  As a reminder the plan is that we get more
>> concrete and knock out holes in the Web API in this document, then
>> rationalize it with the protocol work, and then fold both in to the
>> final group report.  We are mostly still on that first step.
>>
>> Here is my summary of what has changed from the last document, based
>> on the minutes of the last meeting:
>>
>> Done:
>>
>> changes to section 3: remove bind and unbind
>>
>> changes to section 3: add a method to
>> createSpeech[Input|Output]**Request on the SpeechRequest interface
>>
>> changes to section 3: change the type enum to be a bitfield so TTS is
>> 1, ASR is 2, and don't need TTSASR if you have TTS | ASR
>>
>> issue to section 3: remove the state
>>
>> possible issue to 3: we can have multiple of these, should state
>> that, they go away with garbage collection, only issue is how long
>> does the service stay open after a query, do we need some explicit
>> close/reattach (bind/unbind) or do we just not care...
>>
>> changes to section 4: need Query to be more specific if this is on
>> Window
>>
>> changes to section 4: merge filter and options (the criteria is in
>> the option, probably as a flat list)
>>
>> issues to section 4: query needs to be async
>>
>> changes to section 4: add successCallBack and failureCallBack to the
>> specific speechQuery function
>>
>> changes to section 5: Need better definition of "recoable elements",
>> probably listing all such elements
>>
>> issue on section 5: Need a way to get at the SpeechRequest associated
>> with the reco element
>>
>> issue on section 5: have a SpeechInputRequest attribute of reco that
>> is the tied request... this could have the default UA service or a
>> service based on URI attribute. From scripting if you get a new SIR
>> you can set the attribute to associate the new SIR with this reco
>> element
>>
>> issue on section 6: same kind of idea with section 5, with a
>> SpeechOutputRequest instead of SpeechInputRequest issue for section 6
>> (and generally): Link to the definitions in HTML 5 (for
>> HTMLMediaElement, but also for "potentially playing", etc.)
>>
>> Notes about: issue on section 3 or 4: possibly need a way to check if
>> you have permission to do recognition, method on Service (or on
>> Query?)
>>
>> issues to section 4: need a function to return the service based on
>> the URI for the service
>>
>> changes to section 4: filter on required languages and required
>> service type and possibly other things...
>>
>> changes to section 4: possible filter on audio codecs as well
>>
>> issues to section 4: need a way to do authorization, possibly as a
>> name/password options in query options, possibly as authorization for
>> an authorization header, possibly just as proprietary stuff on the
>> URI
>>
>> Not done/no changes: issue to section 4: maybe have constructor and
>> set things?
>>
>> changes to section 5: possible remove form attribute or control...
>> possibly not since this really does tie it to the element properly
>> section 5: htmlFor is definitely fine, later discussion sounds like
>> control is fine too
>>
>> issue to section 5: need some sentence about security model, but that
>> probably ties to request object and not the reco element
>>
>> possible issue for section 6: think about CSS audio last call and if
>> it effects section 6
>>
>>
>>
>>
>>
>> ______________________________**__________ From:
>> public-xg-htmlspeech-request@**w3.org<public-xg-htmlspeech-request@w3.org>
>> [public-xg-htmlspeech-request@**w3.org<public-xg-htmlspeech-request@w3.org>]
>> on behalf of Young, Milan
>> [Milan.Young@nuance.com] Sent: Wednesday, September 07, 2011 4:03 PM
>> To: Dan Burnett; public-xg-htmlspeech@w3.org Subject: RE: [agenda] 8
>> September 2011
>>
>> I also need to send my regrets for this week.
>>
>>
>> -----Original Message----- From: public-xg-htmlspeech-request@**w3.org<public-xg-htmlspeech-request@w3.org>
>> [mailto:public-xg-htmlspeech-**request@w3.org<public-xg-htmlspeech-request@w3.org>]
>> On Behalf Of Dan
>> Burnett Sent: Wednesday, September 07, 2011 11:45 AM To:
>> public-xg-htmlspeech@w3.org Subject: [agenda] 8 September 2011
>>
>> We will have a teleconference this week as planned.
>>
>> Agenda:
>>
>> 1. Web API discussion
>>
>> Since neither Bjorn nor I expects to be able to attend this week's
>> call, we will not be going through any more issue topics in the draft
>> report this week.
>>
>> I propose that we have the following meetings be focused on the
>> listed topics: 15 September:  Web API discussion for 60 minutes, then
>> Protocol discussion or outstanding topics, whichever is most needed.
>> 22 September:  Protocol wrap up for 30 minutes, then Web API
>> discussion 29 September:  Web API wrap up
>>
>>
>> -- dan
>>
>>
>> ============== ==Telecon info == ==============
>>
>> Date:  Thursday, 8 September 2011 Time:  Noon (New York), 1800
>> (Central Europe), 0100 (Tokyo) Duration:  90 minutes
>>
>> US telephone number:  +1.617.761.6200 France telephone number:
>> +33.4.26.46.79.03 UK telephone number: +44.203.318.0479
>>
>> Conference code:  48657# (HTMLS#)
>>
>> Info on using Zakim:  http://www.w3.org/2002/01/**UsingZakim<http://www.w3.org/2002/01/UsingZakim>Irc
>> channel:  #htmlspeech
>>
>> =================== = Recent minute-takers = =================== 1
>> September:  Glen Shires 4 August:  Robert Brown 28 July:  Milan
>> Young 7 July:  Dan Burnett 30 June:  Debbie Dahl 16 June:  Patrick
>> Ehlen 9 June:  Raj Tumuluri 2 June:  Michael Johnston 19 May:
>> Michael Bodell 12 May:  Dan Druta 5 May:  Charles Hemphill 28 April:
>> Robert Brown 21 April:  Olli Pettay 14 April:  Milan Young 7 April:
>> Debbie Dahl 17 March: Dan Burnett 17 February: Bjorn Bringert 16
>> December: Robert Brown 9 December: Dan Druta 2 December: Raj
>> Tumuluri 18 November: Milan Young, Dan Burnett 11 November: Debbie
>> Dahl
>>
>
>
>