See also: IRC log
<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
... started with use cases
<scribe> ... completed almost a year ago
Debbie: It was unclear how to
move that work 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
Olli: Wanted simple apis
Dan: This is not styling
... more focused on dialogs
... than simple input/output
Debbie: XG only focused on JS
... CG had no markup
<smaug> that was CG
<smaug> XG report http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech-20111206/
Judy: Advanced notice has been
... 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
... 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
... 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
... 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
... need to make it as part of the requirements
Dan: CSS might be a better use
... 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
... 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
... 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 ]
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/that/than/ Succeeded: i/Google has driven the CG API/scribenick: burn Succeeded: i/something that came out/scribenick: Milan Succeeded: s/is the/if the/ Succeeded: s/on having a standard/on having a single standard/ FAILED: i/is the direction of the CG API/scribenick: burn Succeeded: i/if the direction of the CG API/scribenic: burn Succeeded: i/if the direction of the CG API/scribenick: burn Succeeded: s|scribenic: burn|| Succeeded: s|i/is the direction of the CG API/scribenick: burn/|| Found Scribe: Milan Inferring ScribeNick: Milan Found ScribeNick: burn Found ScribeNick: Milan Found ScribeNick: burn ScribeNicks: Milan, burn WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: AndroUser2 Dan DanB David David_MacD_Lenovo Debbie Gottfried Gottried Jim Judy Milan Olli bjkim burn dbaron ddahl evanli inserted joined kaz scribenick smaug speech You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 31 Oct 2012 Guessing minutes URL: http://www.w3.org/2012/10/31-speech-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]