See also: IRC log
<burn> scribe: Milan
<burn> ScribeNick: Milan
Dan: Any concerns with last week's minutes?
All: None
Dan: Le's finish up req 18
<mbodell> http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0096.html
Michael: Remaining Issue is about the codec
<burn> milan: want local implementations but know it is unpopular
<burn> milan: or at least well-defined remote protocol
<burn> michael: agreed on the latter, and already addressed via our newest requirements
<burn> milan: want a new requirement about eventing
<burn> bjorn: already added last week
<burn> milan: is this part of the protocol?
<burn> robert: yes, we imply that protocol must support these requirements
<burn> milan: anything in protocol that will define the session, eg cookies?
<burn> robert: this is premature to discuss.
<burn> milan: need to require way to indicate session
Thanks Dan!
I'll pickup soon
<burn> robert: right. may need to add something
<burn> robert: may need some logging capability as well
<burn> bjorn: we already added parameter passing requirement. can use other mechanisms to do logging (eg xmlhttprequest)
<burn> robert: regarding local reco engines, can require that it shoudl offer same functionality as we would get from this protocol
<burn> bjorn: isn't that implied already?
<mbodell> FPR11 could have text to say parameters include session information and logging strings
<burn> milan: local app could integrate using remote protocol
<burn> bjorn: yes, but could also implement directly without using the protocol
Dan: If these are new requirements, we should do this by email
Michael: Can we agree on the codec piece?
<mbodell> candidaye text: There should be at least one mandatory-to-support codec that isn't encumbered with IP issues and has sufficient fidelity & low bandwidth requirements
Dan: IP issues could get sticky, but OK for now
<mbodell> s/standard/stadard/
There should be at least one mandatory to support codec that isn't encumbered with IP issues and has sufficient fidelity & low bandwidth requirements
All: agreement
Michael: #7 - Sounds like we have consensus
<mbodell> requirement: Web application must be able to specify domain specific custom grammars.
All: agreed
<mbodell> new requirement for R5: Web application must be notified when speech recognition errors and non-matches occur.
<burn> milan: are we considering non-reco errors as well?
<burn> milan: missing grammar and nomatches are different
<burn> michael: intent is to be notified on anything that isn't a match in addition to matches
Milan: Suggest Michael's statment added to discription
All: agreed
<mbodell> new requirement: (text description include intent and no input and no matches and errors)
Michael: Consensus over email to drop this requirement
All: agreed
<burn> requirement we just agreed to drop was #30
<mbodell> candidate text for R26: There should exist a high quality default visual user interface for the speech recognition
<bringert> "User agents must provide a default interface to control speech recognition."
Bjorn: We had consensus on different wording
All: Agreed with Bjorn's wording
Michael: General consent to update requirment to require explicit consent if local capture takes place
<mbodell> new requirement: web app should be given captured audio access only after explicit consent from the user
All: Agreed
<burn> unagreed
Bjorn: This wording suggests that UAs are required to provide audio
<burn> milan: why shouldn't it be required?
<burn> bjorn: haven't discussed required yet
Debbie: Are there other ways in which media may be captured? What about other methods?
Michael: Uncomfortable with the word raw because it doesn't cover codec modifications
<ddahl> we can't prevent raw audio capture in general because e.g. Media Capture API can also capture audio
All: agreed
<mbodell> original requirement: Web application must be able to specify language of recognition
Michae: Several questions on this one (Milan missed these)
Robert: Use cases are vauge
Bjorn: Drop down in web app to select language, and then user speaks in that language
Michael: Is this an example of a parameter in the protocol?
<burn> bjorn: this is more than a parameter
<burn> bjorn: this has applicability beyond reco-specific params
Micahel: Will be both standard parameters and implementation specific params
Dan: Are we talking about this specific req, or more general topic about the kinds of information for web-app to send to recognizer
<burn> bjorn: this is a regular parameter, but it's important enough to call it out in the requirements
<burn> michael: and the mechanism for specifying it is still TBD
<burn> bjorn/michael: suggest that any parameter that anyone believes is important be sent as separate reqirement so we can discuss
<burn> general agreement that this requirement is okay as-is
<burn> marc: does this cover synthesis as well?
<burn> michael/bjorn: no. should send separately for tts
<mbodell> new requirement: Web application must be able to specify language of synthesis.
Dan: Objections?
All: None. Agreed
Bjorn: Other aspect was wehther
web-apps could query list of supported langs
... Web apps should get a list of supported languages
<mbodell> bjorn suggested additionally: Web apps should have access to a list of the languages supported by the current speech service implementations.
<marc> I think Olli's comment is here: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0108.html
Olli: Some sort of comment regarding mobile devices
<Raj> yes
Olli: This could lead to fingerprinting
Robert: Unclear which service UA would be querying
Michael: If choice is missing, should return an error or make best effort
Dan: Similar to conflict in SSML
Robert: Might be nice to have en-* be a fallback to en-AU
Dan: Came up with a mechanism in
SSML to select which traits were most important in
selection
... Basically a priority ordering
... This is just one option. Could specify there is no
substitution
... Did this because didn't want to create an API to
querty
... Because sometimes just wanted something to be rendered
Bjorn: Want a use case where the
user is presented with a drop down
... UA must provide that list
Dan: Have a direct conflict with Olli's fingerprint concern
Olli: For example, cannot query
keyboard local
... only can use this while typing
<burn> michael: analogy is getting info on which language is being used but not ability to query for list of available languages
<burn> bjorn: propose we create the requirement to get list of languages and then will prioritize later
<burn> michael: how about 2 reqs: one to get list and one to prevent list?
Dan, I have to leave
<burn> milan, sorry, thought you had 90 minutes. okay
Michael: Put in both requirements, but then sort it out later
<burn> scribe: Dan_Burnett
<burn> scribenick: burn
marc: regarding fingerprinting, this only involves local speech services, right? so web-based would not be an issue?
olli: yes, mainly local
michael: no, default user agent rather than local/remote. if default is remote then issue is the same
bjorn: would like to see second requirement be generalized
<mbodell> bjorn's proposed new requirement 1: Web apps should have access to a list of the languages supported by the current speech service implementations. (with discussion text that this may have issues with privacy and fingerprinting)
robert: would like to see more substantial use cases from bjorn for having the list
bjorn: how do you handle multilingual users? this is necessary
robert: dan's example showed how this could work without an explicit list
<mbodell> second proposed requirement: Web applications should not be able to fingerprint or profile the user, for example through getting a list of languages?
bjorn: if web app wants to show UI to user to select a language, will only work if web app has a list
dan: maybe this is a consent issue -- user needs to give consent for the list to go to the web app
robert: don't see this happening
bjorn: two-way language translator for tourists, where user sets local and remote langauges.
raj: this can even be app-wide, but part of the app could be in a different language
michael: in both of those examples, need to be able to specify language. this could be done by specifying language you want
raj: apps do have need to specify language spoken in ways other than through keyboard or UI
bjorn: maybe have consensus around requirement that when lang requested by web app is not available a fallback can be specified
raj: we should specify that web
apps are notified when requested lang is not available
... similar to notifying that reco resource is not
available
michale: maybe better is "must be
able to be notified"
... we don't want to require that an error occur
<mbodell> possible agreement requirement: Web application must be able to be notified when the selected language is not available
however, not yet agreement on having list of supported languages available -- will take to the list if anyone cares to push for it
bjorn: what about: web apps should be able to check if a particular UA supports a specific language
olli: in practice that's the same
as having the list
... the app would just try all the languages
michael: could also do this by trying a bunch of recos in a row anyway
bjorn: yeah, but user interface would be terrible, so probably won't happen
raj: irrelevent. one is about which langs are supported, the other is about what happens if lang not available
we agree on the notification part. will take the rest to the list
dan: anything else that needs to be brought up today?
michael: on vacation in two weeks, but will have the reqs doc updated and communicate by email
no meeting next week because of thanksgiving
eeting: HTML Speech Incubator Group Teleconference
Date: 18 November 2010
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) FAILED: s/mandatory-to-support standard/stadard/ Succeeded: s/mandatory-to-support standard/standard/ Succeeded: s/standard codec/mandatory-to-support codec/ Succeeded: s/raw/captured/ Found Scribe: Milan Found ScribeNick: Milan Found Scribe: Dan_Burnett Found ScribeNick: burn Scribes: Milan, Dan_Burnett ScribeNicks: Milan, burn Default Present: Bjorn_Bringert, Dan_Burnett, marc, Olli_Pettay, Milan_Young, Michael_Bodell, +1.425.580.aaaa, Debbie_Dahl, Raj_Tumuluri, Dan_Druta Present: Bjorn_Bringert Dan_Burnett marc Olli_Pettay Milan_Young Michael_Bodell Satish_Sampath Debbie_Dahl Raj_Tumuluri Dan_Druta Robert_Brown Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/0145.html Found Date: 18 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/18-htmlspeech-minutes.html People with action items:[End of scribe.perl diagnostic output]