16:01:07 <RRSAgent> RRSAgent has joined #htmlspeech
16:01:07 <RRSAgent> logging to http://www.w3.org/2011/06/16-htmlspeech-irc
16:01:17 <burn> trackbot, start telcon
16:01:19 <trackbot> RRSAgent, make logs public
16:01:21 <trackbot> Zakim, this will be 
16:01:21 <Zakim> I don't understand 'this will be', trackbot
16:01:22 <trackbot> Meeting: HTML Speech Incubator Group Teleconference
16:01:22 <trackbot> Date: 16 June 2011
16:01:26 <burn> zakim, aacc is Dan_Druta
16:01:26 <Zakim> +Dan_Druta; got it
16:01:32 <Zakim> + +1.425.830.aadd
16:01:43 <burn> zakim, nick DanD is Dan_Druta
16:01:43 <Zakim> ok, burn, I now associate DanD with Dan_Druta
16:01:52 <burn> zakim, aadd is Charles_Hemphill
16:01:52 <Zakim> +Charles_Hemphill; got it
16:02:09 <burn> zakim, nick Charles is Charles_Hemphill
16:02:09 <Zakim> ok, burn, I now associate Charles with Charles_Hemphill
16:02:14 <burn> zakim, who's here?
16:02:14 <Zakim> On the phone I see +1.818.237.aaaa, Milan_Young, [Microsoft], Michael_Johnston, Dan_Burnett, Michael_Bodell, Olli_Pettay, Dan_Druta, Charles_Hemphill
16:02:16 <Zakim> On IRC I see RRSAgent, satish, DanD, mbodell, Charles, Zakim, smaug, burn, Milan, Robert, trackbot
16:02:35 <burn> zakim, aaaa is Patrick_Ehlen
16:02:35 <Zakim> +Patrick_Ehlen; got it
16:02:49 <burn> zakim, [Microsoft] is Robert_Brown
16:02:49 <Zakim> +Robert_Brown; got it
16:03:01 <MichaelJ> MichaelJ has joined #htmlspeech
16:03:44 <Zakim> -Olli_Pettay
16:04:20 <burn> Scribe: Patrick_Ehlen
16:05:37 <ehlen> ehlen has joined #htmlspeech
16:05:38 <burn> satish, will you be joining us today?  or anyone from Google?
16:05:47 <burn> zakim, nick ehlen is Patrick_Ehlen
16:05:47 <Zakim> ok, burn, I now associate ehlen with Patrick_Ehlen
16:05:52 <burn> ScribeNick:  ehlen
16:06:11 <burn> zakim, who's here?
16:06:11 <Zakim> On the phone I see Patrick_Ehlen, Milan_Young, Robert_Brown, Michael_Johnston, Dan_Burnett, Michael_Bodell, Dan_Druta, Charles_Hemphill
16:06:14 <Zakim> On IRC I see ehlen, MichaelJ, RRSAgent, satish, DanD, mbodell, Charles, Zakim, burn, Milan, Robert, trackbot
16:06:14 <smaug> smaug has joined #htmlspeech
16:06:27 <burn> Chair:  Dan_Burnett
16:06:39 <burn> Agenda:  http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Jun/0033.html
16:06:45 <satish> burn: I can't join the conf call as I'm on a train, hence only in IRC
16:06:56 <satish> burn: Bjorn is still on paternity leave, not sure about Glen Shires
16:07:24 <Zakim> +??P21
16:07:29 <burn> satish, thanks.  Hopefully Glen will join.  We will be making decisions today about other discussion topics
16:07:33 <smaug> Zakim, ??21 is Olli_Pettay
16:07:33 <Zakim> sorry, smaug, I do not recognize a party named '??21'
16:07:51 <smaug> Zakim, nick smaug is Olli_Pettay
16:07:51 <Zakim> sorry, smaug, I do not see a party named 'Olli_Pettay'
16:08:01 <ehlen> Topic: New design decisions?
16:08:18 <smaug> Zakim, ??P21 is Olli_Pettay
16:08:20 <Zakim> +Olli_Pettay; got it
16:08:34 <smaug> Zakim, nick smaug is Olli_Pettay
16:08:34 <Zakim> ok, smaug, I now associate you with Olli_Pettay
16:08:37 <ehlen> robert: is audio recording without recognition be supported?
16:09:00 <ehlen> are there important scenarios for supporting recording without recognition
16:09:51 <burn> satish, any update on markup binding?
16:10:12 <ehlen> topic: markup binding
16:11:33 <satish> burn: None, Bjorn was collecting input from the chrome team and since he has gone on leave I have no contact on what the status was. 
16:12:21 <burn> satish, can you please check?  we are not waiting on the answer, but it would be nice to have the input
16:12:21 <ehlen> robert: google issue on whether there should be a button to press
16:12:43 <satish> burn: yes, I can take an action to get a definitive answer in the next few days.
16:13:07 <ehlen> burn: satish will take this on w/ the chrome team
16:13:12 <ehlen> topic: discussion time
16:13:36 <ehlen> topic: do we need to support audio recording with recognition?
16:14:38 <ehlen> burn: an advantage could be endpointing.
16:14:47 <ehlen> ... is that an important criteria in this case as well?
16:15:15 <ehlen> charles: another question is how real-time is the reco response?
16:15:23 <ehlen> ... a recording may result in reco later
16:16:22 <ehlen> ... an identifier might later associate the recording with a reco transcription
16:16:50 <ehlen> burn: brings up question of whether we support reco on recorded audio
16:17:54 <ehlen> robert: garbage models could be used to make recording in edge cases
16:18:01 <ehlen> ... "overloading" recognition
16:18:15 <ehlen> ... or will recording be a more common task
16:18:48 <ehlen> ... Do we think recording with endpointing is important?
16:20:18 <ehlen> milan: channel adaptation, sharing headers in same structure, parameters could be reused; sharing the same network paths -- convenient to use same
16:21:09 <ehlen> Charles: Also, the on-line vs. off-line cases
16:22:20 <ehlen> milan: would most recording be associated with an attempt to understand the text in the recording?
16:23:00 <ehlen> burn: Most significant feature is the endpointing
16:23:26 <ehlen> milan: in that case, why not just use dict model, do reco, and save the waveform as backup?
16:24:06 <ehlen> ... and how common would that be. If not so common, could use a garbage model (even a "first-class" one)
16:24:41 <ehlen> burn: seems strange to call recording a weird special case of reco
16:26:04 <ehlen> burn: in favor of using the recording resource as described in mrcp
16:27:16 <ehlen> robert: though endpointing may be valuable, would we support a "record" object in the API? how would this go all the way to the developer?
16:27:44 <ehlen> burn: does not seem to be in our scope
16:28:00 <ehlen> olli: there are other proposals that would handle recording
16:28:54 <ehlen> charles: channel adaptation
16:30:39 <ehlen> burn: channel normalization is not a valid reason for recording support
16:31:32 <ehlen> charles: should probably also include built-in record grammar
16:32:04 <ehlen> (milan above)
16:35:03 <ehlen> milan: use case: may want to to do dictation in parallel with c&c 
16:35:21 <ehlen> ... e.g., provide a c&c followed immediately by dictation
16:36:18 <ehlen> burn: but does that really belong as a built-in type in a grammar?
16:36:33 <ehlen> ... sounds like there is not real consensus today vis-a-vis supporting a recording capability
16:37:06 <ehlen> robert: have not heard a compelling reason to support recording
16:38:08 <ehlen> burn: consensus not to do it now
16:38:23 <ehlen> milan: would like a standard way to do it, should the need arise
16:38:55 <ehlen> burn: we could state that we reserve this for the future
16:39:14 <ehlen> milan: there should be some consistent and portable way to do this across engines
16:39:59 <ehlen> robert: could be done as a proprietary extension
16:40:37 <ehlen> milan: at least provide a consistent hack, like builtin:record
16:40:45 <ehlen> robert: that's what the garbage model recording would be
16:41:27 <ehlen> milan: that's fine, as long as all engines support this type of garbage model
16:42:30 <ehlen> burn: to summarize, can't agree on specific recording scenarios
16:42:46 <ehlen> (robert above)
16:43:06 <ehlen> ... should agree on supporting garbage-recording scenario
16:43:26 <ehlen> burn: as a group, agree not to define an explicit recording capability at this time.
16:43:47 <ehlen> ... can be supported using a garbage model, or capabilities defined outside this group
16:45:05 <ehlen> topic: what are the built-ins, and what does that mean?
16:45:55 <ehlen> milan: existing builtins: dictation, search, address, numbers
16:46:07 <ehlen> robert: already agreed there should be a certain set of predefined grammars
16:46:14 <ehlen> ... so how do we refer to those?
16:46:53 <ehlen> burn: 2 things make builtins interesting: (1) parameterization; (2) no language is required
16:50:05 <ehlen> milan: markup already has certain defined types, parameters, etc, as native to HTML5. Would make sense to pay attention to that here
16:50:34 <ehlen> burn: an unconstrained text box should naturally bind to a dictation model 
16:50:54 <ehlen> milan: should we remap the names of the builtins?
16:51:58 <ehlen> burn: argue strongly for using html as a starting point
16:52:33 <ehlen> robert: These should be builtins, not re-used vxml grammars
16:53:19 <smaug> could someone paste a link to voicexml's builtin grammars ?
16:53:27 <ehlen> charles: they've become a de facto standard; not supporting them is awkward
16:54:16 <Robert> these are the HTML input types: http://www.w3.org/TR/html5/the-input-element.html#attr-input-type
16:54:24 <ehlen> burn: if someone wants to support legacy builtins in a way that doesn't break existing builtins, that's not a problem
16:54:28 <Robert> perhaps have builtins that match these
16:57:00 <ehlen> charles: there needs to be some way to include these
16:57:23 <ehlen> (milan above)
16:57:51 <ehlen> ... is there something about this that can't be represented by a query string?
16:59:06 <ehlen> michael: do you want to reference, for example, an html number type, or some arbitrary number?
17:00:37 <ehlen> milan: easier to use old builtins & augment them
17:00:52 <ehlen> charles: need to look at greater good of using html vs vxml
17:01:21 <mbodell> Widely implemented?  See http://en.wikipedia.org/wiki/URI_scheme
17:04:51 <ehlen> burn: michael, how would you reference grammars that are assoc. with html input types?
17:06:00 <ehlen> michael: an html ruleref, with various attributes; or don't specify URI and ref them by markeup AP...
17:06:16 <ehlen> ... most important is associating grammars with individual input elements
17:08:37 <ehlen> ... not a strong use case to have URIs for these things, or ability for user to write their own that reference these
17:10:05 <ehlen> burn: when people want to hack something up quickly, common input types should lend themselves to being included as part of a larger utterance
17:10:20 <ehlen> michael: may be other ways to specify input for that type of scenarios
17:11:33 <ehlen> burn: maybe reference not the grammar but the input type itself
17:12:58 <ehlen> charles: similar input types not always require the same grammar
17:14:02 <ehlen> burn: but the app author may want a way to link these different types of builtin grammars together 
17:14:50 <ehlen> milan: perhaps just do the proposal
17:15:43 <ehlen> burn: who on the call is interested in builtin models?
17:16:16 <ehlen> charles: interested in it; this group seems focused on web search and dictation, as opposed to broader html cases
17:16:25 <mbodell> <input type="search" name="q" speech required onspeechchange="startSearch">
17:17:28 <ehlen> michael: there will probably be a standard set of grammar libraries, though perhaps the market will provide those
17:17:57 <ehlen> johnston: can't see us requiring something like a "zip code" lib, for internationalization reasons
17:18:10 <ehlen> burn: HTML has already handled a lot of these issues
17:18:21 <ehlen> (milan above)
17:18:43 <ehlen> (michael, above, actually)
17:18:51 <mbodell> s/burn/michael/
17:20:04 <ehlen> milan: should there be an html binding?
17:20:42 <ehlen> michael: would be better if you could speech enable certain input types with little work
17:22:09 <ehlen> robert: if no builtins were specified, what are the consequences?
17:22:49 <ehlen> burn: if you want broad adoptability and usage, it needs to be as easy to create simple apps as vxml
17:23:15 <ehlen> robert: we need it to do the html binding.
17:23:49 <ehlen> ... so how much do we need the html binding part?
17:24:06 <ehlen> milan: definitely need the capability to specify search, dictation, etc.
17:24:31 <ehlen> robert: that's different from looking at html input types, etc. that's a complex problem
17:24:55 <ehlen> milan: would like to have a notion of how to solve binding problem before we do dictation
17:25:58 <ehlen> robert: does anyone have a proposal to volunteer?
17:26:11 <ehlen> milan: perhaps can do it after I get the dictation stuff out
17:26:56 <ehlen> micheal: there is a topic in the API about markup bindings. 
17:27:10 <ehlen> burn: true that it's a binding issue
17:28:13 <ehlen> burn: without a proposal, it doesn't happen. 
17:28:23 <ehlen> ... so it will be up to someone to write a proposal
17:28:36 <ehlen> milan: perhaps sending a message to google on this
17:28:42 <ehlen> robert: or to satish
17:29:11 <ehlen> burn: action item for milan to talk with satish and ask for help on structuring a proposal
17:29:34 <ehlen> burn: reminder: no call next week
17:29:49 <ehlen> robert: but there will be a protocol meeting
17:30:52 <Zakim> -Michael_Bodell
17:30:53 <Zakim> -Milan_Young
17:30:56 <Zakim> -Robert_Brown
17:31:07 <Zakim> -Olli_Pettay
17:31:08 <Zakim> -Patrick_Ehlen
17:31:09 <Zakim> -Michael_Johnston
17:31:23 <Zakim> -Dan_Burnett
17:31:24 <burn> zakim, bye
17:31:24 <Zakim> Zakim has left #htmlspeech
17:31:25 <Zakim> leaving.  As of this point the attendees were +1.818.237.aaaa, Milan_Young, +1.973.452.aabb, Michael_Johnston, Dan_Burnett, Michael_Bodell, Olli_Pettay, +1.425.580.aacc, Dan_Druta,
17:31:27 <Zakim> ... +1.425.830.aadd, Charles_Hemphill, Patrick_Ehlen, Robert_Brown
17:31:33 <burn> rrsagent, make log public
17:31:38 <burn> rrsagent, draft minutes
17:31:38 <RRSAgent> I have made the request to generate http://www.w3.org/2011/06/16-htmlspeech-minutes.html burn
17:32:34 <burn> Regrets:  Raj_Tumuluri, Bjorn_Bringert
17:35:28 <burn> s/+1.818.237.aaaa, //
17:35:41 <burn> s/+1.973.452.aabb, //
17:35:57 <burn> s/+1.425.580.aacc, //
17:36:12 <burn> s/+1.425.830.aadd, //
17:36:16 <burn> rrsagent, draft minutes
17:36:16 <RRSAgent> I have made the request to generate http://www.w3.org/2011/06/16-htmlspeech-minutes.html burn
17:37:18 <burn> rrsagent, bye
17:37:18 <RRSAgent> I see no action items