HTML Speech Incubator Group Teleconference

09 Dec 2010


See also: IRC log


Michael_Bodell, Olli_Pettay, Dan_Burnett, Robert_Brown, Milan_Young, Debbie_Dahl, Dan_Druta, Satish_Sampath, Bjorn_Bringert
Dan Burnett


<burn> trackbot, start telcon

<trackbot> Date: 09 December 2010

<burn> Scribe: Dan_Druta

<burn> ScribeNick: DanD

<burn> Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0069.html

Minutes from last call

burn: There were some issues with the minutes

mbodell: I think I captured them

<burn> Dan's followup email about the minutes: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0071.html

burn: No need to update the minutes

new version of the req draft

<burn> Draft is: http://www.w3.org/2005/Incubator/htmlspeech/live/draft-20101209-requirements.html

burn: No issues with the requirements draft

R34 - http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0064.html

mbodell: Threre is consensus
... drop R34

<burn> nick Robert is Robert_Brown

R32 - http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0067.html

mbodell: consesnus to keep it

R19 - http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0068.html

mbodell - Consensus to drop - out of scope

R11 - http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0065.html

<burn> DanB proposes (instead of Bjorn's wording): "The User Agent and protocol must not prevent web applications from integrating input from multiple modalities."

burn: New wording proposed

ddahl: concern includes the API in the protocol

<burn> possible adjustment to: "Web applications must not be prevented from integrating input from multiple modalities"

<burn> agreement/disagreement?

ddahl: OK with the wording

<satish> I got dropped, having difficulty joining in.. will keep trying.

burn: we got consensus on the wording

R09 http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0060.html

mbodell: There are a few comments

<mbodell> bjorn's proposed requirements: 1. The web app should be notified when TTS playback starts.

<mbodell> 2. The web app should be notified when TTS playback finishes.

<mbodell> 3. The web app should be notified when the audio corresponding to a TTS <mark> element is played back.

burn: I agree with the 3 proposed requirements

ddahl: we can always add later

<burn> olli also agrees and notes that we might want to add more later

Robert: Agreed

burn: on the long email we need to decide how to wording
... if you look at SSML 1.1 it will be nice to receive a notification
... the decision we got so far should be sufficient if we agree and we can add later

ddahl: if we look at less used events we can spend a lot of time

burn: no disagreements

R13 http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0066.html

mbodell: there was quite a conversation about this one

burn: we can't know all the security threats are going to be

<bringert> trying to join, getting "all circuits are busy now"

<bringert> trying french number

<burn> DanD: want to separate notification from communication

<bringert> french number worked

<burn> ddahl: does communication mean http/html?

<burn> bringert: customization is great but can have security problems

bringert: we pretty much agreed but it's hard to word it

ddahl: would it be possible to relate to other requirements?

bringert: we should allow customisation unless it violates other requirements in this requirements

burn: unless it violates other requirements in this doc

ddahl: than we need to make it clear what req
... we get into maintenance problems

bringert: typing the wording for review

<mbodell> security requirements: 10, 16, 17, and 18

burn: we can be specific and miss or be vague and open

<burn> michael: we should be specific about what we know now and include a clause that covers the future

<bringert> "Web apps should be able to customize all aspects of the user interface for speech recognition, except where such customizations conflict with security and privacy requirements in this document, or where they cause other security or privacy problems."

ddahl: we create a spec and it gets implemented and a security problem comes up. Are we not compliant?

<mbodell> can/should we list which are the "security and privacy requirements in this document". I think 10, 16, 17, and 18 but do others agree or notice others?

<bringert> FPR1

dand: we should be specific where it's clear and leave an open window for unknown

bringert: Michael already listed the requirements

<bringert> maybe FPR20

<bringert> "The spec should not unnecessarily restrict the UA's choice in privacy policy."

bringert: 1, 10, 16, 17, 18 and 20 apply

<mbodell> so our list to date is 1, 10, 16, 17, 18, and 20

mbodell: we should use the statement with the list of requirements
... we got consensus on that

R23 http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0038.html

bringert: Hard to follow all the comments in the email
... we should continue and ask if there's an actual requirement
... We tend to agree that we can do with the API's for multimodal apps

mbodell: Our current req in the doc and the existing API's are sufficient

<mbodell> I think the agreement is that our current requirements for Speech XG + existing html is sufficient to do multimodal applications

<mbodell> and that closes r23

UA/SS - http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0062.html

mbodell: this is getting a little bit away from requirements

bringert: it is valuable to discuss

Milan: As long as it's possible for the web app to talk with the speech service we shoud be fine

Robert: we need to get back on topic - Standard protocol

mbodell: we have requirements to address this

bringert: one standard protocol was required if we go thru the browser

Robert: how do evaluate Satish's proposal

Milan: if we can't access the audio and we have to do it thru the browser we need a common protocol

mbodell: we should not drop any requirements, evaluate the email conversation and determine if we need additional req

Milan: They should work consistently in all browsers

mbodell: we already have a lot of req that we need to go back to

Milan: Can we have an update on the audio standards?

bringert: DAP is in early phases and we shoudl provide input to them

<smaug_> DAP is not Device API

<burn> smaug_, please explain

burn: there are several streaming protocols

<ddahl> there is a Media Capture spec published by the W3C DAP group that we might want to look at http://dev.w3.org/2009/dap/camera/

Milan: how time sensitive is this?

<burn> smaug_, so you mean that the work of the W3C Device API WG (group name called "DAP") is not the same as the Device API work in the WHATWG

bringert: we should start working with other groups and experiment

Robert: we need to determine what are our audio requirements

bringert: it should be web app to speech service requirement

<ddahl> there's also a Media Capture API http://www.w3.org/TR/media-capture-api/, I'm not sure what the relationship is

mbodell: this is in conflict with requirements FPR30 and FPR31

Milan: let's modify Robert's req about the codec

mbodell: are there any req missing?
... are there any req that we havent talked and agreed on

burn: this week we need to close in any additional req
... Req 12 is agreed on
... based on lack of comments in email

mbodell: there was an action for me

burn: there was a request to write text to those requirements that don't have any description

mbodell: I'm a little bit nervous about writing text other than what was agreed in minutes and email

burn: I agree with Michael to be concerned about the wording
... the next step is to get in more detail and come with proposals
... wording might change

mbodell: some are self explanatory
... description should come part of the prioritazation

burn: if there are any missing req send them until next week

bringert: can we have a clean version of the requirements?

burn: Michael will clean up

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/12/09 18:56:08 $

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 proposes/DanB proposes/
Succeeded: s/17, 17,/16, 17,/
Succeeded: s/other req/requirements FPR30 and FPR31/
Found Scribe: Dan_Druta
Found ScribeNick: DanD
Default Present: Michael_Bodell, Olli_Pettay, Dan_Burnett, Robert_Brown, Milan_Young, Debbie_Dahl, Dan_Druta, Satish_Sampath, Bjorn_Bringert
Present: Michael_Bodell Olli_Pettay Dan_Burnett Robert_Brown Milan_Young Debbie_Dahl Dan_Druta Satish_Sampath Bjorn_Bringert
Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0069.html
Found Date: 09 Dec 2010
Guessing minutes URL: http://www.w3.org/2010/12/09-htmlspeech-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]