HTML Speech Incubator Group Teleconference -- 04 Aug 2011

<burn> trackbot, start telcon

<trackbot> Date: 04 August 2011

<burn> Scribe: Robert_Brown

<burn> ScribeNick: Robert

Decide on next step for group after original charter expires at end of August

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

Discuss action items needed as a result of item 1

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

Time permitting, discuss the Web API.

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

- DRAFT -

HTML Speech Incubator Group Teleconference

04 Aug 2011

Attendees

Contents

Decide on next step for group after original charter expires at end of August

Discuss action items needed as a result of item 1

Time permitting, discuss the Web API.

Summary of Action Items

Scribe.perl diagnostic output