HTML Speech Incubator Group Teleconference

11 Nov 2010

See also: IRC log


Debbie_Dahl, Olli_Pettay, +39.335.766.aaaa, Marc_Schroeder, Dan_Burnett, Michael_Bodell, Paolo_Baggia, Milan_Young, +1.760.705.aabb, Bjorn_Bringert, +1.425.391.aacc, Robert_Brown, Dan_Druta, +44.122.546.aadd


trackbot start telcon

trackbot, start telcon

<trackbot> Date: 11 November 2010

<marc> yes

<smaug_> ah

minute takers and expectations

<scribe> scribe: ddahl

dan: important to start and end on time
... in the future we will track when people take minutes, also will prefer to to select people who join late and haven't taken minutes
... will start asking newer people in the coming weeks
... suggestion that we check on f2f minutes and requirements draft
... send minor corrections to minutes by email, or bring up major corrections now.

<scribe> ...new requirements draft sent out based on f2f discussion by Michael Bodell

<smaug_> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0102.html

michael: started new section and struck out requirements that have been deleted. the new draft just covers f2f

dan: concerns about requirements?

<burn> agenda is at http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0104.html

marc: should this requirements document be at a stable uri?

michael: would like to do this, but still need CVS access

dan: we're going through this process as quickly as we can
... this is supposed to be more of a live draft
... comments on requirements?

paolo: would like to know more about section 4, is that the place where the new changes will be placed?

michael: yes
... as we go through this, all of section 3 will be moved, but section 4 will replace it
... confusing to mix old and new requirements

dan: paolo, were you asking if there was a way to link old and new requirements?

paolo: yes, and in the old one there was explanation

michael: was mainly trying to capture what we agreed on rather than include a lot of text

<scribe> ...new ones link back to old ones

dan: this approach reduces confusion about which are the new requirements, when we finish the old requirements I will ask if there's anything that didn't get captured, then it will be safe to remove old requirements.


dan: start with R21

michael: status is that there was mostly agreement that it was out of scope, was not sure what the scenario was that Eric Johansson had in mind.

dan: recommend drawing a line through this requirement and letting Eric raise concerns

bjorn: i think Eric agreed that it was out of scope

dan: he may want to continue discussion


michael: we already covered this in discussion of R27

<burn> for the minutes, also note that we explicitly had consensus on the call to remove R21

dan: does anyone object to removing R6?

(no objections)


michael: little discussion, but some bleeded over from R18
... should have requirement that API for recognition should not introduce unneeded latency

dan: any more comments on R17?

<bringert> my connection dropped, dialing again

dan: any objections to Michael's wording to replace R17

michael: two requirements, one that Bjorn proposed and one that Michael proposed
... first one is that applications can start processing captured audio right away and second says that applications should not unneeded latency

dan: any objections to replacing original R17 with these two requirements?

(no objections)

<smaug_> "Implementations should be allowed to start processing captured audio before the capture completes." and "The API to do recognition should not introduce unneeded latency."


<bringert> (w3c doesn't answer the phone), no objection from me

<burn> bjorn, just try again. zakim does this sometimes

dan: we acknowledge no objections to R17 (including from bjorn)
... we will do what we can on R18, will get started while waiting for bjorn
... any objections?

<mbodell> Implementations should be allowed to start playing back synthesized speech before the complete results of the speech synthesis request are available.

dan: any objections to adding this requirement?

michael: other proposals that may have come out of this discussion.
... other issues about what user agent must allow, codecs, not sure how to tackle

dan: there are others where we're closed to consensus, so let's start with those
... some of the ones proposed by Milan were addressing other wording on email list

milan: first two, about writing and reading to the audio buffer is handled

bjorn: we might have consensus on the requirement about unneeded latency
... for TTS

marc: we agree with this

michael: that takes care of the first 3, and the others aren't needed
... then we had user agents must not filter results from the application

<burn> no, not "the others aren't needed" -- instead, the next 3 are not needed

<burn> ... through filtering results

bjorn: the next two are that the ua must not interfere with result or timing

<burn> oops, i meant through passing parameters

<burn> yes, we are now discussing results and timing

olli: you might have some results that are suspicious
... that the ua might want to filter

marc: what speaks in favor of these requirements?

milan: concerned that ua think that it knows best about the speech interaction and deleting something that was part of the protocol between the speech resource and the web application

michael: api needs to be extensible so that additional functionality is supported?

milan: actually wants to make sure that if an EMMA result is sent to the web app the ua must not change it because it doesn't know what it is? also wants events fired by the speech resource to make it into the user space.

olli: what kind of event are you talking about?

<burn> actually, that was olli

<burn> (not bjorn)

<mbodell> Yeah, I think ealier too about supspicious results was also olli

milan: if we have a "start of speech" event, as long as our API is flexible enough we can add new things
... API should be flexible so that new events don't break apps

bjorn: how about if we say that it should be possible to add new information to speech recognition results
... then for events we would have to require that speech server specific events would be able to be returned to the web app

milan: web applications need to be able to continue to run even if they aren't expecting them

bjorn: can't expect that app will never crash
... so speech server should be able to return implementation-specific events
... two new requirements

<bringert> new requirement 1: speech recognition implementations should be allowed to add implementation specific information to speech recognition results

<bringert> new requirement 2: speech recognition implementations should be allowed to fire implementation specific events

milan: previously we had discussed that there was a particular ordering of events, if we just have events being fired in between those events, we might destabilize applications

bjorn: the apps that don't care about events won't register for them. and if we say "a before b" that doesn't mean that there's not anything in between.

milan: if speech server doesn't generate "start of speech" does the ua insert it?

bjorn: we haven't defined events

michael: it could be the ua or the speech resource that generates some of these events

dan: any objections to adding these two requirements as stated on IRC

milan: are we going to allow TTS to fire events? these just talk about recognition.

marc: it would make sense to have that?

michael: rather than changing R2 to speech resources would it make sense to have new requirement for TTS events?

bjorn: other use cases for TTS events other than "mark"?

marc: yes, "mark" is too coarse-grained for lip synchronization

<mbodell> new requirement 3: speech synthesis implementations should be allowed to fire implementation specific events

dan: sounds like we have agreement on these three

michael: back to R18

dan: should be split into two, first is exactly as worded

michael: i.e. requires support for remote services, e.g. by HTTP 1.1

dan: yes, second is that speech services and ua may negotiate on other protocols
... first one is mandatory support for HTTP 1.1

michael: does HTTP 1.1 include https?

marc: this seems like a low-level technical requirement, should not discuss now

dan: two issues -- we use a generic term "communication" but we might need to distinguish control and media
... at IETF there is a lot of discussion for using HTTP for streaming, when should you use that or not
... we might not want to define these protocols, just pick from what's available, but may not want to pick now

marc: would like to settle on some existing protocol, but now is too early

michael: likes rewording with "such as"

robert: likes "lowest common denominator"

<smaug_> that wasn't me

<mbodell> that was robert

marc: requirement should be: the communication between the us and the speech server muat allow for some lowest common denominator like HTTP 1.1

dan: we want to require a lowest common denominator protocol

bjorn: we want to avoid mismatch between browser and speech server communication

<burn> i said "require a mandatory-to-support communication protocol, such protocol TBD"

michael: the communication between the us and the speech server muat require a mandatory-to-support lowest common denominator such as HTTP 1.1, TBD

dan: the reason for this is that four months from now it might be construed as requiring HTTP 1.1

michael: do we have agreement on this?
... ok what about the second sentence?

dan: we could write a requirement but may not end up considering it as something that we need to do now
... we don't want to prevent negotiation in the future

robert: negotiation sounds like a runtime handshake but what we really want is the freedom to use something else if something better shows up
... in telephony negotiation is important, but in web apps you just ask for what you want and if it doesn't work, try something else

dan: this concept is important to capture

michael: requirement text?

<burn> what i had proposed initially was: "UAs and speech services may negotiate on use of other protocols for communication."

michael: another wording: "UAs and speech services may agree to use alternate protocols for communication."

dan: agreement?

(no objections)

<mbodell> agree with another wording

marc: another one for R18, should we have one for implementation data for TTS, a mirror image to the new one we added for ASR

robert: we added that at the f2f

michael: two more
... require ua's to expose an API for local speech services

bjorn: i don't see this as necessary

michael: i agree

dan: do you think that whatever API we define should be sufficient?

bjorn: the ua is free to talk to any speech service whenever it wants

<burn> my question is whether even in the local case that the single api we are defining should be required

<burn> ... and that UAs can optimize the behavior

<burn> or are you saying that the UA can do anything it wants any way it wants when the resource is local?

bjorn: as long as the specification is specified, if the web app requests a local speech service but it's not available, what happens

milan: we have a stereotype that a local speech service is embedded, but it could be a plug in. so if the app requests a local service, that should be honored.

bjorn: what if it's not there?

milan: if it's a plugin you might ask the user if they want to install a plugin

bjorn: to make that work we would have to specify a plugin language

milan: agree, but if a local service is requested it should be used

michael: isn't this an example of the web app requesting an alternate speech service?

milan: don't expect to require downloading of code

bjorn: how could this work without downloading code?

milan: we don't need to specify, just say that there has to be some mechanism

bjorn: what if we say that web app could point to a local service, but we shouldn't say that the ua has to try to install a local service

olli: what if some vendor only makes plugins for, i.e. IE

<bringert> that was olli

michael: we should have a requirement that speech services can specify a local service

<mbodell> new req: Speech services that can be specified by web apps must include local speech services.

dan: if we agree on this requirement, if someone wants to propose additional requirements we can discuss

michael: if the ua refuses resource it must inform web app (we already have this one)

<burn> so we have agreed to add this new requirement

michael: don't distinguish between network and local

milan: what does "default speech resource"?

<burn> we are now discussing the related FPR9 and 10 to understand whether we need to add anything else

michael: in the future the author should be able to just ask for speech service without specifying one

bjorn: a browser must provide speech service, it doesn't have to build its own

<smaug_> I may not agree with the requirement

dan: it sounds like we do have agreement with this requirement

<smaug_> I need to think about it a bit

<Milan> Who is smaug?

michael: can we remove R18 and discuss codecs later

<smaug_> smaug is Olli

dan: we could keep R18 just for that last point
... milan's concerns about R18 haven't been addressed
... next call next week


Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/11/11 18:32:58 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/dan: R6/topic:R6/
Succeeded: s/can introduce/should not/
Succeeded: s/bjorn: what/olli: what/
Succeeded: s/bjorn: you/olli: you/
Succeeded: s/that doesn't mean that there's anything/that doesn't mean that there's not anything/
Succeeded: s/olli: likes/robert: likes/
Succeeded: s/us/ua/
Succeeded: s/us/ua/
Succeeded: s/??/olli/
Found Scribe: ddahl
Inferring ScribeNick: ddahl
Default Present: Debbie_Dahl, Olli_Pettay, +39.335.766.aaaa, Marc_Schroeder, Dan_Burnett, Michael_Bodell, Paolo_Baggia, Milan_Young, +1.760.705.aabb, Bjorn_Bringert, +1.425.391.aacc, Robert_Brown, Dan_Druta, +44.122.546.aadd
Present: Debbie_Dahl Olli_Pettay +39.335.766.aaaa Marc_Schroeder Dan_Burnett Michael_Bodell Paolo_Baggia Milan_Young +1.760.705.aabb Bjorn_Bringert +1.425.391.aacc Robert_Brown Dan_Druta +44.122.546.aadd
Found Date: 11 Nov 2010
Guessing minutes URL: http://www.w3.org/2010/11/11-htmlspeech-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]