W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > May 2011

[minutes] 19 May 2011 telecon

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 19 May 2011 21:02:47 -0400
Message-Id: <47309029-F07C-4A30-A9CD-039D6A7E3DF1@voxeo.com>
To: public-xg-htmlspeech@w3.org

The minutes from today's call are available at http://www.w3.org/2011/05/19-htmlspeech-minutes.html 

For convenience, a text version is embedded below.

Thanks to Michael Bodell for taking the minutes!

-- dan



           Dan_Burnett, Michael_Bodell, Olli_Pettay, Robert_Brown,
           Debbie_Dahl, Patrick_Ehlen, Bjorn_Bringert, Raj_Tumuluri,
           Dan_Druta, Milan_Young, Charles_Hemphill, Michael_Johnston


           Dan Burnett



      * [4]Topics
          1. [5]F2F logistics
          2. [6]Updated final report document
          3. [7]other agreed-upon design decisions
          4. [8]How do we talk to a remote speech service, and how much
             needs to be supported
      * [9]Summary of Action Items

    <burn> trackbot, start telcon

    <trackbot> Date: 19 May 2011

    <burn> Scribe: Michael_Bodell

    <burn> ScribeNick: mbodell

    <burn> Agenda:

      [10] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0011.html

F2F logistics

    Dan: There is a summary page on the logistics of the F2F at:

    <burn> logistics page:

      [11] http://www.w3.org/2005/Incubator/htmlspeech/group/2011/05/f2f_logistics.html

    bjorn: There is a light weight NDA to sign before arriving

    Dan: Can we get a copy early?

    bjorn: No it only exists there. But I think you can sign no.

    <scribe> ACTION: Bjorn will verify that signing the nda is not
    required for attending the f2f. [recorded in

    <trackbot> Created ACTION-3 - Will verify that signing the nda is
    not required for attending the f2f. [on Bjorn Bringert - due

Updated final report document

    Dan: the link in the email is wrong. The text is correct. The mail
    program made too many links.

    charles: I thought item 24 was too strong

    Dan: Let's talk about that. "It must not be possible to customize
    the "system is listening" (microphone open) notification. This is
    for security and privacy reasons." The hope was that if you can
    customize it you could customize it out of existiance.

    Charles: Well I think that is perhaps valid but there may be other
    choices like have 3 different flavors of browser UI and the web ap
    could choose which one it is.

    Olli: The web application should not be able to override the browser
    controls. Perhaps in the browser chrome.
    ... Perhaps 2 different notifications: One in the browser chrome
    that can't be customized and maybe one in the web app that can be

    Dan: That's interesting and new, but I think that Charles's 3
    choices still matches that.

    Robert: This is over complicated. I think this is similar to https
    with mismatched certificate where the browser has a notification
    from the browser on the page that the web application has no control
    over. But the browser shouldn't interfear with the web application.

    Bjorn: I don't think we can specify how the browser displays the

    Dan: So the browser chrome must support a notification that can not
    be over ridden.

    Bjorn: I don't like saying chrome as it implies a certain type of
    browser and certain type of notification.

    Dan: User agent instead?

    DanD: I like user agent better as it matches other scenarios like in
    the car.

    Bjorn: Yes user agent works.

    <scribe> ACTION: Dan will modify 24 on the document to reflect this
    discussion. [recorded in

    <trackbot> Sorry, amibiguous username (more than one match) - Dan

    <trackbot> Try using a different identifier, such as family name or
    username (eg. dburnett, ddruta)

other agreed-upon design decisions

    Dan: Is it too early to go to IDL definitions and discussion like
    the reco discusion started by

      [14] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011May/0013.html

    Robert: I think it is too early, just because it may distract us
    from our major issues to discuss, but then it is apporiate to
    discuss things like the idl over email quickly.

    Bjorn: I had a couple of purposes: one, to make sure that I was
    covering everything we agreed with, even if we hadn't discussed it
    (I.e., we all agree on maxresults but we haven't discussed it yet);
    two, to show how much agreement we've had.

    Dan: We have had a lot of agreement. I think it is ok to have this
    low priority discussion on email, but the main focus of discussion
    will be the issues.
    ... Any other agreements?

    Bjorn: Maxresults? I think everyone has these.

    Dan: do we agree?

    Bjorn: Microsoft and Google had it and Olli agreed in email.

    Robert: I agree.

    Dan: Alright, we have agreement on maxresults.
    ... Any others?

    Bjorn: I think maybe timeout. Not positive if we have agreement here
    or not, but I think timeout is probably agreed.

    Dan: We've had the discussion of all the different events we support
    (end of speech, etc.). not sure if this is separate.

    Bjorn: That reminds me that item 30 doesn't work. We have sound end
    as a low latency event (I.e., might be energy detected). But then
    we'd have soundend event before a speechdone.

    Dan: I think that is solved because by definition you'd raise a
    speechdone automatically when you'd have a soundend so you'd know
    there was a soundend and then send both in order.

    Bjorn: I'm ok with that.

    Dan: We agree, how about others?

    Robert: I think this is the wrong discussion to have, surely we have
    more important issues to discuss than the details of the ordering of
    these events.

    Dan: Fair enough, we can go back to this topic later.

How do we talk to a remote speech service, and how much needs to be

    Bjorn: We agreed http needs to be supported.

    Dan: We did agree to "We will require support for http for all
    communication between the user agent and any selected engine,
    including chunked http for media streaming, and support negotiation
    of other protocols"

    Bjorn: what is left? what to specify?

    Dan: Yes, what to specify.

    Milan: If we can pass arbitrary properties do we need anything else?

    <Robert> FYI, here's the proposal we made:

      [15] http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#http_conventions

    Michael: We may want to specify how certain well defined parameters
    are passed, like maxresults, but that should have a set way to do

    Bjorn: I'd rather the parameters *not* end up as query params as I'd
    want the uri that is specified in the web app might be
    host/reco?webappparam1=foo&webappparam2=bar and other parameters
    would go some other method (post body, headers, something)

    MichaelJ: Strawman proposal, all parameters go over http query

    Bjorn: You could do that, but the problem I have with that is that
    then the user will be mucking with the uri to add the grammar

    MichaelB: I don't think that is the issue, you could have the JS API
    have addGrammar() and it would let the browser know how to add the
    parameters and muck with the uri. That is easy for it to do. The
    danger with all URI paramaters is most proxies and webservers will
    chooke on uri larger then some number (1K, 2K, and 4K are all common
    size limits). So if you wanted to send audio or a large grammar
    you'd hit that.

    Bjorn: Yeah, I agree with this as a problem.

    Milan: Maybe what goes on the url is engine specific?

    Bjorn: That would be good for me.

    Milan: But maybe you want language or something.

    Bjorn: I don't think even then you would put the language on the

    Milan: So even that would go in the header.

    MichaelB: Header has other issues, multiline grammar as a header is

    Bjorn: Yeah, post body.

    Milan: fine, post body, I was being general with headers.

    Dan: So do we have agreement that no parameters will be in the url

    <burn> No, that's not what I said

    MichaelB: My one concern is that while I agree the API should be the
    prefered way to set certain values; however, in most web services
    today you can set parameters on the uri or as post parameters and
    you can do either. So in the maxnbest parameter if setMaxNBest(3)
    sets a post body great. But if the user knows that, and chooses to
    set their speech service uri as server.org/reco?maxnbest=3 then that
    should be fine for the user to do if that is their pre

    <burn> ah, yes it is -- sorry, I was behind

    Bjorn: that seems fine, but if the user then does that and calls the
    api the value will be specified in the post body as well, and if it
    is specified in both places the body wins

    Robert: YEah, that sounds right. That way the api doesn't need to
    change the uri values.

    DanD: That sounds right to me as well.

    Bjorn: I think that's the way we'd have to do it as the URI is
    completely opaque to the user agent so it can't enforce anything on
    the uri

    <burn> - User agent will use URI for ASR engine as given by the web
    app -- it will not modify it.

    <burn> - Scripting API would set its values in the POST body.

    <burn> - If engine allows params to be specified in the URI in
    addition to in the POST body, then conflicting ones in the body have
    precedence. This has the effect of making parameters set in the URI
    be treated as default values.

    Dan: Added to the minutes the general summary agreement.
    ... Any other questions on this topic?

    Charles: Last week we talked about web sockets or streaming, does
    "the body" work out in these cases?

    Bjorn: Not sure we've decided on POST versus headers versus some
    other part of the request

    Robert: I thought we did agree that.

    Bjorn: Ok, we said header or body and header has issues so we should
    be fine on saying POST body

    Robert: Agree. Are we further agreed on multipart/formdata?

    MichaelB: Might also be multipart/mixed.

    Bjorn: Yeah, the agreement is that separate post body of type
    multipart but the exact sub-mime type of multipart/mixed versus
    multipart/formdata versus multipart/foo is not agreed

Summary of Action Items

    [NEW] ACTION: Bjorn will verify that signing the nda is not required
    for attending the f2f. [recorded in
    [NEW] ACTION: Dan will modify 24 on the document to reflect this
    discussion. [recorded in
Received on Friday, 20 May 2011 01:03:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:49 UTC