See also: IRC log
<burn> trackbot, start telcon
<trackbot> Date: 07 April 2011
<smaug_> good, apparently the network is good enough here
<burn> Scribe: Debbie Dahl
<burn> ScribeNick: ddahl
<scribe> Meeting: HTML Speech XG
bjorn: several people have asked
for rooms
... is there anyone else?
dan: I will need a room
bjorn: I need the maximum number
of days that you'll stay there.
... is anyone opposed to a better hotel, costs 7 GBP
more?
... i will switch us to a better hotel
... will send out a form to see how many are coming
dan_druta: will come and let you know.
raj: will come
bjorn: nothing else about arrangements
danB: new person
patrick: Patrick Ehlen from ATT
dan: for each proposal would like
to hear a quick summary of what your proposal does and doesn't
do with respect to the other proposals.
... proposers should just take the floor and discuss, even if
other proposers may want to make a correction.
... bjorn starts.
bjorn: MS proposal, there aren't
a lot of commonalities between ASR and TTS.
... is that correct?
danB: will discuss later
bjorn: MS includes both a
Javascript API and a browser-server protocol
... would like to break these apart
... sums up MS proposal, but thinks that MS API and Google
proposal could be merged.
... Mozilla proposal is similar to Google, but Mozilla doesn't
allow user-initiated recognition without a permission prompt,
but Google does, and this is an important use case for
us.
... the proposal for the WebApp API could say what
implementation is used, and there could be a different proposal
for how the browser talks to that implementation.
olli: how does Google's proposal do that without click-checking?
bjorn: the browser must make it clear that it's starting recognition
dan: click jacking or click checking?
bjorn: should be click jacking,
not checking
... there should also be click checking to make sure that it
was really the user.
dan: switch to olli's discussion now.
olli: the differences are minor.
wasn't thinking much about the network engine.
... about Google's proposal it seems that it would be difficult
to handle multiple fields at once
... that's one reason why X+V was so difficult
... wouldn't like to bind recognition results to one input
field
... also, user-initiated recognition, i don't see the
difference if the user is clicking something and that starts
recognition, that could be ok at first, so I don't see the
difference between Mozillas and Google's proposals.
... MS proposal using Web Sockets is minor but could be good if
we want to allow remote speech engines
milan: question for Olli, you said that we must handle click-jacking?
<burn> that was Milan
olli: not sure how Google's proposal handles this
milan: in summary, you don't find that sufficient?
olli: no
robert: I agree that if you look
at high level scripting API the proposals are similar.
... the high level speech semantics are very similar and we
should be able to converge pretty easily.
... there are only so many ways to build a speech API
... one of the things that we're trying to achieve is to allow
a lot of openness so that the ASR and TTS is not determined by
the manufacturer of the browser.
... one thing I'm concerned about with Google and Mozilla is
that there's an intent to handle that later, but I think it
needs to be handled now. we need in the first version to handle
some interopability.
... what could we do to provide a simple protocol with existing
API's. we proposed XHR, but Web Sockets would be fine. we
wanted to say that it's not a hard problem.
... the second comment is that we tried to take a
scenario-focused approach. our document specified a half-dozen
or so apps, and tried to think about requirements.
... this is why we put ASR and TTS into the same spec
... there are a number of scenarios that would be difficult if
the speech was just built into the browser
... a comment about user-initiated speech. we're skeptical that
just having a button that the user pushes insures
privacy.
... there will be many kinds of devices, we believe that
consent should be built into the browser implementation.
... we don't want the speech API to be a de facto microphone
API, we should provide microphone requirements into an existing
effort.
... on the question of v1 vs v2. we aren't opposed to a second
version, but we don't want v1 just to be the easy things, it
should include the important things.
... regarding TTS, it takes the things that seem to work from
the media element, but not the things that don't apply, like
multiple tracks.
dan: questions for Robert?
milan: robert, how does your proposal handle a default recognizer?
robert: you use a constructer without that parameter, if there are multiple recognizers availble you could use those parameters to select an appropriate one.
danB: this disussion will be more unstructured and open. next week we'll have a more structured discussion. first bjorn will get a chance to respond.
bjorn: regarding olli's point
about multiple input fields, you could do that with scripting,
or we could use something like MS.
... (missed comment about random selection)
... on the question of whether clicking implies consent, we say
that clicking could imply consent, but there could be other
ways. Also agree that other engines could be used, but one way
to do that would be, for example, Nuance, to write a
plugin.
... you could have a Javascript API with a parameter that says
which engine would be used.
... would like some clarification on what use cases couldn't be
supported by default recognizer
... we agree that we don't want to work on microphone API
dan: the floor is open. question
for bjorn about the click-to-speak issue
... there could be a button to click but that doesn't
necessariy imply consent. it is still the browser's
responsibility to insure consent.
bjorn: a button could insure consent.
dan: the browser could even treat lack of clicking for consent with some use cases.
raj: another use case for not using the default recognizer might be if you have an SLM, which aren't interoperable.
danB: does Google.com want the
default recognizer in IE to be the MS recognizer?
... individual sites may have a strong preference for a
recognizer to be used.
robert: for example, Nuance have a lot of enterprise customer care speech applications, and customers will want to leverage that investment.
danD: if the web developer wants to specify an engine they should be able to do that. the browser should provide a default. also the user should be able to specify a recognizer.
danB: if the user has asked for another recognizer, then web application should be able to not render.
robert: we've already agreed to this
bjorn: doesn't disagree
jerry: what about local resources?
bjorn: everyone agrees on that
jerry: many free-form grammars would only work with certain engines
bjorn: we have broad agreement. with MS proposal we could split control of recognizer from selection of recognizer.
robert: in principle that would be reasonable, but don't want to lose track of one of those topics.
danB: what we do with TTS and ASR
should be synchronized.
... some use cases only involve TTS, for example.
<Milan> Milan: reluctant to split the solution (tts, asr, protocol) into many documents because vendors may choose to implment only select pieces
bjorn: two different things, ASR
vs. TTS and web app vs. server
... does anyone have concerns about splitting?
milan: only that browsers might cherry-pick specs
robert: would not ratify one spec if the other wasn't satisfactory
michaelB: if they were together it would be easier to keep things in synch.
bjorn: the web app api could be done, and then the server-side one could depend on that.
michael: the questions about synch and ratifying at the same time argue for one proposal.
danD: if we had two efforts it would speed up adoption but it still should be one spec.
bjorn: there should be a single API for the web app and another one for how the browser talks to the engine.
milan: I had a proposal for a way to unify the Mozilla proposal and MS proposal by using macros over the MS proposal to make it look more like Mozilla.
bjorn: that's mostly syntactic
<burn> Milan's email (thread): http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Mar/0040.html
milan: the MS proposal talks to the server in the web app
danD: we should move away from syntax to more declarative types of statements.
robert: not sure, for example, in SALT, html elements were simple, but then you had to write a lot of scripting
bjorn: this is a different discussion
michaelJ: it's important to keep specification of API to the server because there will be a lot of overlap between the API's. we don't want to end up with different names for things.
milan: but we had separate specification, they should be ratified together.
bjorn: that seems reasonable, and
they should be developed in parallel
... they could be separate so that people who write webapps
only have to look at one thing. Also, they could go to
different standards organizations.
danB: at IETF, talked about real-time collaboration between web browsers (RTC web) won't be working on new protocols. the interface from browser to engine will introduce some requirements.
bjorn: there could be several
protocols for talking to servers, so that more could be added
later
... for example, VoiceXML and SRGS aren't in the same spec
milan: we agreed that there should be a protocol for communicating to a speech server.
danB: there could be a "mandatory
to implement" requirement. any web app API is not complete
unless it includes a "mandatory to implement" requirement for
server communication that is defined by this group.
... we should begin to do this because our requirements are
different.
robert: VoiceXML/SRGS analogy is different because SRGS can be used independently. both are tightly coupled.
bjorn: web app API makes sense by
itself and also server API
... we are implementing both of those at Google. We have
non-browser clients that use the server API
milan: how about an MRCP over
HTTP protocol?
... are people familiar with MRCP?
bjorn: seems a lot more complex than MS proposal
milan: MS is a simplified version of MRCP
robert: that is kind of what we've done, could also do MRCP over Web Sockets.
raj: MRCP is a good idea, because it's already been implemented, but wouldn't it be overkill for a local system?
milan: most OS's would optimize that
bjorn: it's more than just efficiency
milan: talking about using MRCP paradigm, not full MRCP
dan: MRCP is a protocol that just controls ASR and TTS resources. MRCP v2 makes use of SIP to set up and MRCP session, but from then on all communication is MRCP. milan is talking about the MRCP protocol itself, which doesn't require SIP.
milan: would be willing to stage this.
jerry: MRCP in the browser is very messy.
robert: could we layer MRCP over Web Sockets
milan: i'm not suggesting that developers would program to MRCP, in a web app you would have to have simpler concepts, or the browser could support it, which would totally mask it from the developer.
danD: it should definitely be
abstracted from the web browser
... it will enable both weekend and enterprise developers to
use the spec
dan: any other topics that require discussion?
danD: the proposals lack clarity around privacy, preferences and consent.
bjorn: they should be up to user agents
danD: we need to put some mandates on the developers of user agents.
robert: for example, a way to indicate to the recognizer that it shouldn't log?
danD: yes, should have a very clear indication of what the user can specify or override in regard to the speech interaction
robert: it depends highly on the user agent itself. a cell phone is different from the dashboard of a car or one that's being used by a blind person. I don't feel comfortable mandating something.
danD: for example, where do we display what engine is being used? do we want to have a consistent way for the user to specify their profile?
danB: it seems clear that we must address this topic in a specification
bjorn: about protocols vs. web api's.
<Robert> we also need to discuss microphone API
bjorn: there was discussion about protocols, but we didn't talk much about web api's. we pretty much agree on web api's.
michaelB: not sure about the details.
michaelJ: agree, details need to be worked out.
bjorn: yes, but we seem to agree on high level.
robert: we seem to be moving in the direction of a JavaScript API, although not in HTML, or the protocol.
bjorn: if we start on the web api, there are a lot of things we could agree on.
danB: major issues need to be
worked out early during process, but it's also good to be able
to make progress. so we need to be able to do both at the same
time.
... that is, discuss big issues and work out details of things
we roughly agree on.
michaelB: agree, this is a reason it's useful to have things in the same document.
danB: Michael and I will talk
about how to structure discussion, e.g. write down things we
agree on.
... it might be too soon to work out details of proposals.
robert: one thing we don't agree on is microphone api.
milan: also result format
<smaug_> (we may not need to think about microphone if we move to use audio streams)
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/???/milan/ Succeeded: s/develoers/developers/ Found Scribe: Debbie Dahl Found ScribeNick: ddahl Default Present: Dan_Burnett, Olli_Pettay, Milan_Young, Michael_Bodell, +1.818.237.aaaa, Raj_Tumuluri, Patrick_Ehlen, +1.425.421.aabb, Jerry_Carter, +1.425.391.aacc, Robert_Brown, Dan_Druta, Debbie_Dahl, Bjorn_Bringert, Michael_Johnston Present: Dan_Burnett Olli_Pettay Milan_Young Michael_Bodell +1.818.237.aaaa Raj_Tumuluri Patrick_Ehlen +1.425.421.aabb Jerry_Carter +1.425.391.aacc Robert_Brown Dan_Druta Debbie_Dahl Bjorn_Bringert Michael_Johnston Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/0002.html Found Date: 07 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/07-htmlspeech-minutes.html People with action items:[End of scribe.perl diagnostic output]