- From: Dan Burnett <dburnett@voxeo.com>
- Date: Fri, 19 Nov 2010 13:28:44 -0500
- To: public-xg-htmlspeech@w3.org
- Message-Id: <91201C1C-B373-4F18-A581-A37AFE7B1951@voxeo.com>
Group,
The draft minutes for our call yesterday can be found at http://www.w3.org/2010/11/18-htmlspeech-minutes.html
.
Please let me know of any needed corrections or additions.
For convenience, a text version is below.
-- dan
===============================
Attendees
Present
Bjorn_Bringert, Dan_Burnett, marc, Olli_Pettay, Milan_Young,
Michael_Bodell, Satish_Sampath, Debbie_Dahl, Raj_Tumuluri,
Dan_Druta, Robert_Brown
Regrets
Chair
Dan Burnett
Scribe
Milan, Dan_Burnett
Contents
* [4]Topics
1. [5]R26
2. [6]R28
3. [7]R8
* [8]Summary of Action Items
_________________________________________________________
<burn> scribe: Milan
<burn> ScribeNick: Milan
Dan: Any concerns with last week's minutes?
All: None
Dan: Le's finish up req 18
<mbodell>
[9]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov/
0096.html
[9] 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
R26
<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
R28
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
R8
<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:
[10]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Nov
/0108.html
[10] 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
Summary of Action Items
[End of minutes]
__________
Received on Friday, 19 November 2010 18:29:24 UTC