Sppech and HTML -- 31 Oct 2012

<scribe> scribe: Milan

Debbie: start with introductions

,.. many attempts to integrate speech and HTML

scribe: many attempts to integrate speech and HTML
... first was HTML Speech XG

Dan: Google initiated an W3C incubator group
... started with use cases

<scribe> ... completed almost a year ago

Debbie: It was unclear how to move that work forward
... JavaScript speech API took that forward
... but now we want to move that to an actual standard
... we'd like to discuss how to move that forward

Gottfried: How does this relate to CCS3?

Olli: Unclear how widely that is implemented

Dan: No aware of any attempts to make that work consistent

Gottried: why?

Olli: Wanted simple apis

Dan: This is not styling
... more focused on dialogs
... than simple input/output

Debbie: XG only focused on JS apis
... CG had no markup

<smaug> http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html

<smaug> that was CG

<smaug> XG report http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/

Judy: Advanced notice has been sent
... but need to complete the charter
... lots of interest in the W3C in speech, but it's not clear
... perhaps a map would help interested parties learn the direction

Dan: When trying to define the XG, the clearest statement was not making it VoiceXML
... so yes, I agree

David: What are you trying to do with speech on the web?

Debbie: Many different goals
... 1) Use speech on mobile devices
... ie leverage multimodal environment
... eg want to shop for "red sweaters"
... and use voice to narrow down the list
... put items on wish list

DanB: mobile device use cases are common
... senarios range from simple input to have a conversation
... services may be network or local
... need to select different recognizers
... EG user uses Chrome to go to MS Bing
... MS has enhanced recognizer to use MS recognizer
... without ability to select recognizer, this doesn't work

Jim: Also consider IVR applications ported to the web

Gottfried: Consider accesibility
... eg API that outputs speech to a user

Jim: HTML author has ability to handle that

Dan: For styling, often want to speak something different than just state data

Gottfried: Need to solve these problems in a flexible way. Media type attributes
... need fallbacks should authoring fail

Olli: we haven't focused on accesibility
... need to make it as part of the requirements

Dan: CSS might be a better use case
... if CSS is not sufficient, we might need to change focus of this effort
... might need to get into semantic analysis

Olli: In the existing speech APIs, you can tightly control the output

Debbie: on speech input side, can't require someone always to speak

Judy: must always be multiple input and output options
... not required
... eg government agencies were forcing speech as the only option

Dan: VoiceXML tried to make this work on featureless phones
... language provided capability to allow for key input

Judy: there are some regulatory requirements for multiple inputs

Debbie: good exercise to go through the use cases
... and see if they are consistent with these goals

Dan: No speech case has already been handled
... because this is an HTML environement
... Mike C from Google wanted to have speech available everywhere

<inserted> scribenick: burn

Milan: Google has driven the CG API and is a leading browser vendor. The question is whether the people in this room would be sufficient to create and drive an effective working group.

… charter said the work would be taken out of the CG and worked on in new WG, but Google has said they don't want it to move out of the CG.

… Ian said that something could be put on the CG spec saying that it was produced in CG but new work will be happening in WG. But this is still ugly.

Judy: often in W3C technical topics come up where vendors differ in approach. Very good opportunity in charter development to find agreement, because later in the process it's more expensive to fork. From media format issue, due to regulatory issues there was much interest in broadcast community on having a single standard, but browser vendors differed in opinion. W3C tried to find some common ground.

… broadcast folks complain to W3C that w3C is not creating a standard, but vendors have not reached common ground.

… Probably same need in speech. There has to be discussion about which issues have disagreement. One important piece is ensuring that existing CG work is not misunderstood as a standard. But more fundamental is to have vendors agree on what work to do. Otherwise, w3c will fail to satisfy the rest of us.

… may take longer to get charter launched, but if we don't there will be failure later.

Milan: do we ask for a w3c mediator?

Judy: W3C would rather see a single solution in the end, so we need to find a way to converge approaches. It would be better to have this happen earlier in the process rather than later. Team contacts can help, others if necessary. Tackle the questions.

burn: if questions are political rather than technical??

Judy: yes, that has happened before :) Often they are still technical in the end

… in another group it was very much like this. We started with requirements and discovered that there were differences in requirements for the two sides. Maybe a requirements exercise will help. Sometimes this can point out differences.

Olli: we did spend time on the developments of requirements. Current approach is not too far from the prioritized list of requirements.

Milan: CG met most of them.

Olli: CG only attempted a subset of the requirements.

<inserted> scribenick: Milan

Dan: something that came out of the req process
... different participants believed different priorities were important

Judy: This is a difference between CGs and WGs
... in working group, desenting opinons must be addressed.
... if W3C director agrees, spec can be stopped

<inserted> scribenick: burn

Judy: if the direction of the CG API a set that will prevent filling remaining requirements, then it's a problem.

Milan: No, it's something we can build on.

Judy: this is a good point to be at!
... this is better than some other W3C situations

Debbie: people needing fuller API might want to fork, but I don't think so. Foundation needs features but doesn't prevent proprietary additions.

Milan: let's pull in the CG spec into a WG, get started with implementations and discussion. In the CG, proposed ideas are just met with "no".

Judy: yes, in WG that is not allowed to happen.

<kaz> [ adjourned ]

- DRAFT -

Sppech and HTML

31 Oct 2012

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output