HTML Speech Incubator Group Teleconference -- 18 Nov 2010

<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

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: 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

- DRAFT -

HTML Speech Incubator Group Teleconference

18 Nov 2010

Attendees

Contents

R26

R28

R8

Summary of Action Items

Scribe.perl diagnostic output