See also: IRC log
<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
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
<burn> Draft is: http://www.w3.org/2005/Incubator/htmlspeech/live/draft-20101209-requirements.html
burn: No issues with the requirements draft
mbodell: Threre is
consensus
... drop R34
<burn> nick Robert is Robert_Brown
mbodell: consesnus to keep it
mbodell - Consensus to drop - out of scope
<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
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
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
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
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
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]