- From: Dan Burnett <dburnett@voxeo.com>
- Date: Thu, 19 May 2011 21:02:47 -0400
- To: public-xg-htmlspeech@w3.org
Group,
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
*********************************************************************************************
Attendees
Present
Dan_Burnett, Michael_Bodell, Olli_Pettay, Robert_Brown,
Debbie_Dahl, Patrick_Ehlen, Bjorn_Bringert, Raj_Tumuluri,
Dan_Druta, Milan_Young, Charles_Hemphill, Michael_Johnston
Regrets
Marc_Schroeder
Chair
Dan Burnett
Scribe
Michael_Bodell
Contents
* [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
[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_lo
gistics.html
[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
[12]http://www.w3.org/2011/05/19-htmlspeech-minutes.html#action01]
<trackbot> Created ACTION-3 - Will verify that signing the nda is
not required for attending the f2f. [on Bjorn Bringert - due
2011-05-26].
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
customized.
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
information.
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
[13]http://www.w3.org/2011/05/19-htmlspeech-minutes.html#action02]
<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
[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
supported
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
[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
it.
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
params.
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
uri.
Milan: So even that would go in the header.
MichaelB: Header has other issues, multiline grammar as a header is
problematic.
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
[16]http://www.w3.org/2011/05/19-htmlspeech-minutes.html#action01]
[NEW] ACTION: Dan will modify 24 on the document to reflect this
discussion. [recorded in
[17]http://www.w3.org/2011/05/19-htmlspeech-minutes.html#action02]
Received on Friday, 20 May 2011 01:03:20 UTC