W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > August 2011

[minutes] 4 August 2011

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 4 Aug 2011 14:43:41 -0400
Message-Id: <4A685FF4-D79E-46A7-AE0F-246059B2B95F@voxeo.com>
To: public-xg-htmlspeech@w3.org
Group,

The minutes from today's call are available at http://www.w3.org/2011/08/04-htmlspeech-minutes.html.

For convenience, a text version is embedded below.

(Many) Thanks to Robert Brown for taking the minutes.

-- dan

**********************************************************************************

             HTML Speech Incubator Group Teleconference

04 Aug 2011

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Aug/0006.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/08/04-htmlspeech-irc

Attendees

   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

   Regrets
   Chair
          Dan_Burnett

   Scribe
          Robert_Brown

Contents

     * [4]Topics
         1. [5]Decide on next step for group after original charter
            expires at end of August
         2. [6]Discuss action items needed as a result of item 1
         3. [7]Time permitting, discuss the Web API.
     * [8]Summary of Action Items
     _________________________________________________________

  
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> [9]WebApps Charter

      [9] http://www.w3.org/2008/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:
   [10]http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/06
   60.html and appears to be meeting at TPAC 2011:
   [11]http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/09
   86.html ]]

     [10] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0660.html
     [11] 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
Received on Thursday, 4 August 2011 18:44:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 August 2011 18:44:23 GMT