Re: [agenda] 8 September 2011

On 09/13/2011 03:48 AM, Satish S wrote:
> 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).

I don't know what <reco> has to do with security prompts.
User needs to give permission at some point.
To me <reco> is mainly just a hint for UA to show some
UI for starting speech recognition (before starting recognition there
is some permission UI, if user hasn't given permission in other ways).
The same could be achieved by
letting page to style elements in the way they want to show the UI for
starting speech recognition.



> 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
> <mailto: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
>         <mailto:public-xg-htmlspeech-request@w3.org>
>         [public-xg-htmlspeech-request@__w3.org
>         <mailto:public-xg-htmlspeech-request@w3.org>] on behalf of
>         Young, Milan
>         [Milan.Young@nuance.com <mailto:Milan.Young@nuance.com>] Sent:
>         Wednesday, September 07, 2011 4:03 PM
>         To: Dan Burnett; public-xg-htmlspeech@w3.org
>         <mailto: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
>         <mailto:public-xg-htmlspeech-request@w3.org>
>         [mailto:public-xg-htmlspeech-__request@w3.org
>         <mailto: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 <mailto: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
>
>
>
>

Received on Tuesday, 13 September 2011 16:13:46 UTC