See also: IRC log
<burn> trackbot, start telcon
<trackbot> Date: 04 August 2011
<burn> Scribe: Robert_Brown
<burn> ScribeNick: Robert
Burn: My opinion is we've made
good progress on use cases, requirements and protocol, but not
so much on web API
... as far as XGs go we've done a phenomenal job and are in a
good place to create a working group
... we should either decide to create a working group at the
end of august, or extend a few months then create a working
group
Bjorn: agree. we should extend a
short period to finish the web API work.
... we should not start a new working group. we'd be working in
isolation. better to join an existing working group
Olli: need implementations
Burn: need a working group so we
can get external feedback. working groups create public
document that are on a recommendation track, which will attract
external input
... less important whether it's our own working group or an
existing group
MichaelJ: we'll get lost if we go into a group that's too big
Bjorn: WebApps group may be small enough
Olli: some things need to be removed from WebApps charter
Satish: should talk with WebApps to see if there's a strong reason we shouldn't be there
<smaug> some specs are being removed from web apps to a new wg
Bodell: important thing is that we get on a recommendation track, whether it's a new one or existing one
Olli: removed from WebApps to new working groups
DanD: Could easily just finish our work in our own WG rather than have an extension. Joining an existing WG would slow us down. Better to finish before joining
Bjorn: to decide what to do with WGs, we need to talk to people from existing WGs, and we need to have a piece of work to show them.
Burn: hearing from others that people are forming smaller groups rather than joining larger ones
Matt: what people have said so far makes sense. either way is fine. putting it in the HTML5 WG wouldn't be a good idea. Other WGs working outside the HTML spec have been successful - geolocation
Debbie: important that we agree
to continue on a standards track
... we really do have a lot of work left to do, and if we have
our own group it will be easier to make progress
Olli: or we could spend a lot of time on our own producing something nobody wants
Satish: or what we produce could be inconsistent with existing APIs & practices
Debbie: there's no guarantee that being in a larger group will get us noticed by other members
Satish: reasons for other smaller groups forming may be specific to that group, and different from our reasons (e.g. geolocation)
Matt: geolocation had other reasons. be careful with speech because it's an IP minefield.
Michael: if we're in a web-focused group, are we going to be constantly explaining speech?
Bjorn: we don't have enough web-focus
<matt> s/minefield, so if you go outside w3c, be ware of the patent policies/
Charles: i.e. the web javascript expertise
Bjorn: we don't have any actual web developers or browser developers in the group
Charles: it would be good to put this in front of web developers
Burn: Bjorn's point is that we
need to make this relevant to the web community.
... concerned that if we wrap up as an incubator, there are
people who will treat it as a standard, which is wrong
... how do we get the involvement of the broader web
community
Bjorn: the way to get their involvement is to implement stuff that people can use and get their feedback
Burn: agreed
Bjorn: danger is that we come up with stuff nobody would implement
Burn: if we to form or join a WG, there's nothing to stop us issuing a draft in the same timeframe we would have issued an XG report. Which approach will give us the best feedback? If we're in a WG, which one would give us the best feedback?
<matt> [You can start a WG before the work is done. Start writing a draft now.]
Burn: there's admin time involved in setting up a WG, so deciding early helps
<matt> [You also can't just join a new WG, you have to add to the charter of the existing WG and have it approved, which can lose members if they're unwilling to commit to disclosing patents on the new work]
MichaelJ: own group has startup costs, but IP benefits. least cost of setup is to join the Multimodal WG
Bjorn: has anything from Multimodal WG been implemented in any browser?
Bodell: not in standard web browsers. but for example, Microsoft Office implements the ink spec
Debbie: part of the problem is that speech is a very different technology from other web technology, and in a group with a lot of web-oriented people, there's danger of marginalization. there's a deep investment to get people to understand speech.
Satish: if we can't explain it to WG members, it'll be even harder to explain it to developers
Bjorn: most important thing is to get implementation, even if that means we should dumb it down
Charles: javascript focus puts it in the speech developers area, rather than markup
Burn: agree that the goal is to get implementations developers will use
<matt> WebApps Charter
Burn: WebApps charter seems to
encompass us generically, although speech isn't mentioned
... may be an issue with speech IP. would existing participants
have concerns about speech technology in the group
... Could talk to the chairs/leads of the group. There's a
coordination group call tomorrow that Dan and Debbie will be
in.
Debbie: good idea. no call tomorrow, but there will be one next week.
Dan: but it does delay our
decision
... by at least two weeks. It'll take a month+ to get a new WG
started
<matt> [You can start writing a charter language now, without making a decision, focus on recommendation track deliverables section, groups you will talk to will probably want that information anyway]]
Dan: should email to coordination group to setup the conversation
Olli: (member of webapps) Being in WebApps doesn't guarantee more input. Other groups have been merged without resulting in more feedback. On the other hand, there's work that's proceeding well outside of WebApps
MichaelJ: agree we need to get things implemented in browsers. Disturbing if the only way for that to happen is if it's in certain WGs
Burn: WebRTC isn't concerned about getting feedback. Once they publish something (tomorrow?) they'll get lots more feedback
DanD: WebRTC is good analogy.
Very specific focus and separate group.
... any way to do things in parallel. e.g. extend XG charter
for a month, and start the process of initiating a WG now, then
transition when possible
Burn: yes, and that's what I'd
assume
... if we extend, there's no reason we'd not work on WG
participation or chartering in parallel
... Tech plenary is end of Oct, 1st week of September. May be
the natural point to start a new group if we wanted to. Wrap up
XG before end of October.
Debbie: if we joined an existing WG, this would be the ideal time for a F2F to get to know them
Olli: WebApps has never had any F2F meetings. It's is pretty much email only.
<matt> [[WebApps met at last TPAC]]
Olli: except at the last TPAC
Burn: any other comments on TPAC & timing?
<matt> [[WebApps also appears to have met two weeks ago: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0660.html and appears to be meeting at TPAC 2011: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0986.html ]]
Satish: it's fine to meet in person at TPAC whatever path we choose
Burn: do we agree that if we extend the XG, we'll start standards track work at a specific date, and decide which WG to join/start over the next month?
Bodell: agree
<smaug> WebApps DOM events subgroup has telcons
Bjorn: extend to end of October
means we sustain a high pace until then
... agree with the approach
... don't care about standard as such, care about developers
having an interoperable API
Olli: extending XG sounds good. don't care whether it's a new or existing WG.
DanD: we should extend to October with clear agreement to move into a standards track
MichaelJ: we do need to go into a standards track. we've managed to get things together quickly, and if we don't go into a standards track soon, it will fracture
Burn: not clear that there's agreement from browser implementers about whether we should go into a WG track
Bjorn: not opposed to standardization. just not sure whtether it's the highest priority. but it won't hurt either
Olli: what we'll produce won't be good enough to be an interoperable specification.
DanD: Bjorn's indifference to the next step is well taken, but the report won't be good enough to implement anything interoperable
Bjorn: joining a w3c group isn't the only way to achieve this. the whatwg is, for example, an alternative
Bodell: for some companies and some reviewers, the w3c recommendation track is more important
Olli: agrees with Bjorn that it doesn't matter where the spec is written
Bjorn: agree to extend the XG, and to move to a wider group
Burn: anybody who's opinion on
whether we extend depends on what the plan is for after?
... [silence]
Bjorn: good question. not me
Satish: agree
Bodell: only if our decision was to transition to WG at the end of August, but it sounds like people are okay with extending
Burn: general agreement that we should extend the XG to wrap up the work. general timeframe would be end of October / early November.
Bodell: err on the long date
MichaelJ: watch out for publication moratorium
Bjorn: okay with end-October to end-December
Burn: action items are on me. get the charter extended. talk to people in w3c about where to continue the work if it were to continue in the w3c
Bodell: we could discuss Olli's recent mail
Bjorn: could be get a status? there are a lot of open items on the API
Burn: I'll get to my item as soon as I can, not sure when
Debbie: have two items. sent an update this morning on one, still need to work on getting results back, but open to somebody else taking that (otherwise will take 2 weeks)
Charles: no progress this week, more next week
Bodell: Olli got his done
Olli: [discussion of his capture hooks spec]
Bodell: [general agreement from everybody]
Debbie: discuss design decision 29 - API to provide control over which parts of the captured audio are sent to the recognizer
Bjorn: one use case is where you're capturing audio all the time, but something else in the UI places a boundary around when the user speaks (e.g. a button, visual prompt, etc)
Debbie: not redundant with design decision 28, which had to do with endpointing
Bjorn: anybody have a strong use case for this?
Debbie: could update the design decision
Bjorn: happy to not obey this design decision
Debbie: how do we retract a decision?
Bjorn: Dan puts a strike-through in the final report?
Burn: or not copy it into the official section. have some ideas for how to handle this sort of thing
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) FAILED: s/minefield, so if you go outside w3c, be ware of the patent policies// Succeeded: s/It's email only/It's is pretty much email only/ Succeeded: s/, +1.650.279.aaaa// Succeeded: s/, +1.408.359.aabb// Succeeded: s/Matt/Matt_Womer/ Succeeded: s/I'm having VoIP server issues// Found Scribe: Robert_Brown Found ScribeNick: Robert Default Present: Dan_Burnett, Robert_Brown, Patrick_Ehlen, Milan_Young, Michael_Johnston, Olli_Pettay, Michael_Bodell, Matt_Womer, Debbie_Dahl, Dan_Druta, Charles_Hemphill, Satish_Sampath, Bjorn_Bringert, Glen_Shires Present: Dan_Burnett Robert_Brown Patrick_Ehlen Milan_Young Michael_Johnston Olli_Pettay Michael_Bodell Matt_Womer Debbie_Dahl Dan_Druta Charles_Hemphill Satish_Sampath Bjorn_Bringert Glen_Shires Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Aug/0006.html Found Date: 04 Aug 2011 Guessing minutes URL: http://www.w3.org/2011/08/04-htmlspeech-minutes.html People with action items:[End of scribe.perl diagnostic output]