IRC log of htmlspeech on 2011-10-20
Timestamps are in UTC.
- 15:48:54 [RRSAgent]
- RRSAgent has joined #htmlspeech
- 15:48:54 [RRSAgent]
- logging to http://www.w3.org/2011/10/20-htmlspeech-irc
- 15:49:02 [Zakim]
- Zakim has joined #htmlspeech
- 15:49:16 [burn]
- zakim, this will be htmlspeech
- 15:49:16 [Zakim]
- ok, burn; I see INC_(HTMLSPEECH)11:30AM scheduled to start 19 minutes ago
- 15:50:57 [burn]
- trackbot, start telcon
- 15:50:59 [trackbot]
- RRSAgent, make logs public
- 15:51:01 [trackbot]
- Zakim, this will be
- 15:51:01 [Zakim]
- I don't understand 'this will be', trackbot
- 15:51:02 [trackbot]
- Meeting: HTML Speech Incubator Group Teleconference
- 15:51:02 [trackbot]
- Date: 20 October 2011
- 15:57:55 [Zakim]
- INC_(HTMLSPEECH)11:30AM has now started
- 15:58:03 [Zakim]
- +Dan_Druta
- 15:58:10 [DanD]
- DanD has joined #htmlspeech
- 15:58:14 [Zakim]
- +Dan_Burnett
- 15:58:52 [ddahl]
- ddahl has joined #htmlspeech
- 15:59:13 [Zakim]
- +Michael_Bodell
- 15:59:14 [Zakim]
- +[Microsoft]
- 15:59:28 [Zakim]
- +Debbie_Dahl
- 15:59:35 [burn]
- zakim, [Microsoft] is Robert_Brown
- 15:59:35 [Zakim]
- +Robert_Brown; got it
- 15:59:56 [mbodell]
- mbodell has joined #htmlspeech
- 16:01:39 [burn]
- zakim, who's here?
- 16:01:42 [Zakim]
- On the phone I see Dan_Druta, Dan_Burnett, Michael_Bodell, Robert_Brown, Debbie_Dahl
- 16:01:44 [Zakim]
- On IRC I see mbodell, ddahl, DanD, Zakim, RRSAgent, burn, smaug, trackbot
- 16:01:53 [Zakim]
- +Glen_Shires
- 16:02:24 [Charles]
- Charles has joined #htmlspeech
- 16:03:00 [glen]
- glen has joined #htmlspeech
- 16:03:36 [Zakim]
- +Charles_Hemphill
- 16:03:51 [Zakim]
- + +1.818.237.aaaa
- 16:04:17 [burn]
- zakim, aaaa is Patrick_Ehlen
- 16:04:17 [Zakim]
- +Patrick_Ehlen; got it
- 16:04:21 [Zakim]
- +[IPcaller]
- 16:04:23 [Zakim]
- +Milan_Young
- 16:04:35 [smaug]
- Zakim, [IPcaller] is Olli_Pettay
- 16:04:35 [Zakim]
- +Olli_Pettay; got it
- 16:04:50 [Milan]
- Milan has joined #HTMLSpeech
- 16:05:00 [burn]
- Scribe: Patrick_Ehlen
- 16:05:00 [smaug]
- Zakim, nick smaug is Olli_Pettay
- 16:05:00 [Zakim]
- ok, smaug, I now associate you with Olli_Pettay
- 16:05:14 [ehlen]
- ehlen has joined #htmlspeech
- 16:05:17 [burn]
- ScribeNick: ehlen
- 16:05:23 [burn]
- Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0030.html
- 16:05:53 [ehlen]
- Topic: reco element
- 16:06:15 [burn]
- Glen's proposal that we're discussing: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0000.html
- 16:06:32 [Robert]
- Robert has joined #htmlspeech
- 16:08:46 [ehlen]
- glen: reco element always visible; opacity not possible to avoid clickjacking
- 16:09:02 [Zakim]
- +??P0
- 16:09:20 [burn]
- zakim, ??P0 is Satish_Sampath
- 16:09:20 [Zakim]
- +Satish_Sampath; got it
- 16:09:37 [ehlen]
- should we allow dynamically hiding/showing reco element
- 16:09:59 [burn]
- s/should we allow/... should we allow/
- 16:12:23 [ehlen]
- milan: user agents can decide what permissions models they use, and grant permissions according to UA policy
- 16:12:50 [burn]
- s/milan:/michael:/
- 16:12:51 [ehlen]
- charles: also important to consier handsfree cases; can't rely on touch for permissions
- 16:14:28 [ehlen]
- satish: reco should automatically activate for ppl who can't touch element ??
- 16:15:46 [ehlen]
- ... there are other ways to "click" reco
- 16:16:20 [ehlen]
- michael: UA could use some of these techniques to enable permissions
- 16:16:42 [ehlen]
- satish: how exactly would this be implemented?
- 16:18:28 [ehlen]
- michael: implement a UI idiom from the browser the user can't control that would notify the user
- 16:19:30 [ehlen]
- binding tag for input field
- 16:19:54 [ehlen]
- ... "speech IME": User agent that can speech-enable any input field
- 16:20:31 [ehlen]
- charles: field-specific reco is better for accuracy
- 16:21:33 [ehlen]
- Milan: allowing developer to bind grammar to a specific field; increases complexity
- 16:22:20 [ehlen]
- ... if developer is sophisticated to do this from an API, make a declarative element makes it more complex
- 16:23:27 [ehlen]
- glen: disagree; gives a lot more flexibility and control to both developer and user
- 16:24:12 [ehlen]
- charles: a lot of web developers only work w/ HTML
- 16:24:45 [ehlen]
- ... not everyone can do thins in javascript, so a declarative ability is advantageous
- 16:25:59 [ehlen]
- glen: keep simple things simple. if we can do something simple w/ reco tag but not UA, then there's a good reason for a reco tag
- 16:26:03 [smaug]
- if someone says he "knows HTML but not JS", he probably doesn't know HTML either
- 16:28:26 [ehlen]
- satish: how to assoc. an element w/ an input type
- 16:28:28 [ehlen]
- glen: isn't it easier to have an automatic binding people can use?
- 16:29:30 [ehlen]
- satish: not clear how it would work
- 16:29:39 [ehlen]
- milan: need to work through list of things that are reco-able elements
- 16:30:00 [mbodell]
- s/milan/michael/
- 16:30:06 [mbodell]
- s/Milan/michael/
- 16:31:27 [ehlen]
- charles: example on website of multiple input fields each bound to a separate grammar
- 16:32:34 [ehlen]
- michael will create specific examples of how binding works for different elements
- 16:34:27 [ehlen]
- Topic: Can extract grammar information from input fields; have a method that allows you to extract grammar from an input field?
- 16:35:27 [glen]
- SpeechInputRequest.addGrammarFrom(DomInputElement)
- 16:35:28 [glen]
- Retrieves grammar from <input> tag and adds to request.
- 16:36:54 [ehlen]
- michael: would UA be responsible for communicating contraints?
- 16:37:05 [ehlen]
- glen: should be reco service that converts into grammar
- 16:37:35 [ehlen]
- ... this would be a way to extract input field specification and sent to speech engine in scriptable manner
- 16:37:36 [burn]
- s/communicating contraints/communicating constraints or would it be responsible for generating and sending the grammar itself/
- 16:38:57 [ehlen]
- burn: Would it be possible then to change these constraints dynamically?
- 16:39:01 [ehlen]
- ... how would it work?
- 16:39:45 [ehlen]
- ... what happens if you do it 2x in a row? would grammar sent before get replaced by newer one?
- 16:40:20 [ehlen]
- michael: should have a way to control the grammar; but how to dynamically remove and change them?
- 16:40:43 [ehlen]
- burn: rename method above to "includeGrammarFrom()" ?
- 16:41:06 [ehlen]
- ... would allow you not to "add" but rather to take a snapshot
- 16:41:32 [ehlen]
- glen: there are other methods that cover these kinds of actions
- 16:41:48 [glen]
- SpeechInputRequest.addGrammarFrom(DomInputElement, weight, modal)
- 16:41:53 [ehlen]
- ... makes sense to add weight and modal flags as well
- 16:42:30 [ehlen]
- glen: would expect api developer to be able to enable & disable grammar
- 16:42:56 [glen]
- SpeechInputRequest.outputToElement(DomElement)
- 16:43:13 [glen]
- Valid DomElements are <input> and <textarea>
- 16:43:24 [glen]
- UA will automatically fill DomElement with results. This allows the UA to display continuous streaming of results, and properly handle text insertion point.
- 16:44:03 [glen]
- Only one DomElement may be active at a time.
- 16:44:16 [smaug]
- request.onmatch = function(e) { domElement.value = e.result; }
- 16:44:32 [ehlen]
- One DOM element active at a time, since you can't stream to 2 different elements
- 16:44:42 [ehlen]
- ... sort of like binding to an element
- 16:45:32 [ehlen]
- Olli: handling of output depends on element type; how would that work?
- 16:46:14 [ehlen]
- glen: UA would find the tricky things, like where to output text, etc.
- 16:46:25 [mbodell]
- For request.onmatch you don't want to just do domElement.value = e.result as it over writes the content in the continuous case
- 16:46:27 [ehlen]
- olli: all that needs to be defined in spec
- 16:46:46 [ehlen]
- glen: for insertion point, handle in a way similar to typing text
- 16:47:53 [ehlen]
- olli: would need to define so many different cases.
- 16:48:15 [ehlen]
- charles: another thing: UA ought to be able to use focus to enable and disable grammars assoc. with input
- 16:48:15 [glen]
- s/UA would find/UA would implement/
- 16:49:31 [ehlen]
- glen: should at least work at trying to specify it, perhaps at f2f
- 16:50:06 [ehlen]
- burn: after tech discussions, there will still be a lot of work on doc, so perhaps doing this at f2f is not realistic
- 16:50:32 [ehlen]
- ... even if we can't fully specify it, that isn't a fail; it shows some thought in that direction
- 16:50:46 [ehlen]
- satish: perhaps choose somehting simpler to start with
- 16:51:03 [ehlen]
- glen: perhaps restrict to just text, date, etc., rather than covering other types?
- 16:51:21 [ehlen]
- michael: can start there and see where we end up
- 16:52:00 [ehlen]
- Topic: Method to attribute conversion
- 16:52:04 [mbodell]
- see mail http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Oct/0037.html
- 16:52:54 [ehlen]
- michael: converting input result params into attributes, but grammar and custom params are more complicated
- 16:53:12 [ehlen]
- ... want some array of simple structures?
- 16:53:58 [Zakim]
- +Michael_Johnston
- 16:54:07 [ehlen]
- robert: arrays tend to be default way of doing things in JS
- 16:54:36 [ehlen]
- michael: array of structure of something like the speech grammar?
- 16:55:05 [ehlen]
- Charles: JS can also utilize objects for structures
- 16:55:32 [ehlen]
- Robert: array isn't strongly typed
- 16:56:47 [ehlen]
- satish: don't need helpers for grammars and speech parameters?
- 16:57:10 [ehlen]
- ... why have all that when you can do it with one attribute
- 16:57:43 [ehlen]
- michael: so leaning toward having these structures but not the methods discussed above?
- 16:58:32 [ehlen]
- Topic: casing
- 16:59:00 [burn]
- Chair: Dan_Burnett
- 16:59:00 [ehlen]
- michael: people expect all caps for objects and interfaces
- 16:59:33 [ehlen]
- michael will make those changes for next week
- 17:00:36 [ehlen]
- Topic: grammar URIs with filters on them
- 17:00:45 [ehlen]
- Robert: it's cool if it works
- 17:01:00 [ehlen]
- ... providing parameters to finite grammars is fine
- 17:01:27 [ehlen]
- ... skeptical of free dictation filter, or whether could be implemented efficiently and therefore won't be used
- 17:01:51 [mbodell]
- builtin:input?type=text&pattern=%5B0-9%5D%5BA-Z%5D%7B3%7D
- 17:02:07 [ehlen]
- ... specifying pattern on input field
- 17:02:16 [ehlen]
- ... how to merge n-gram w/ pattern?
- 17:02:27 [mbodell]
- (which is really builtin:input?type=text&pattern=[0-9][A-Z]{3} )
- 17:02:29 [ehlen]
- ... easy to specify, but prob. hard to ipmlement
- 17:03:00 [ehlen]
- ... will foul up probabilities in ngram model
- 17:03:29 [ehlen]
- michael: such a pattern could be translated into CFG on server
- 17:03:44 [Zakim]
- + +1.407.421.aabb
- 17:03:45 [ehlen]
- ... but this isn't necessarily merged w/ freee text model
- 17:03:45 [Zakim]
- + +1.212.341.aacc
- 17:03:52 [Zakim]
- -Michael_Johnston
- 17:04:16 [ehlen]
- Robert: but pattern doesn't necessarily represent how people will speak it
- 17:04:18 [Zakim]
- -Dan_Burnett
- 17:04:24 [burn]
- zakim, aabb is Dan_Burnett
- 17:04:24 [Zakim]
- +Dan_Burnett; got it
- 17:04:38 [ehlen]
- ... "three four a" vs. "thirty-four a", etc.
- 17:04:56 [ehlen]
- ... or "three boo"
- 17:05:15 [ehlen]
- michael: so it's up to speech service to be good at handling that
- 17:05:49 [ehlen]
- glen: this is a new way of specifying grammars, that many existing speech services don't do now
- 17:06:00 [ehlen]
- Robert: regex doesn't include any kind of normalization
- 17:06:22 [Milan]
- s/glen/Milan
- 17:07:13 [ehlen]
- Michael: real question: is it legal for speech engine to ignore such hints (or patterns) and return something that has nothing to do w/ it? (would hope so)
- 17:07:39 [ehlen]
- Robert: Looks great on paper, but won't be implemented
- 17:09:50 [ehlen]
- Milan: Nothing stopping speech providers to offer this
- 17:10:15 [burn]
- s/offer this/offer this but reluctant to standardize at this point/
- 17:10:41 [ehlen]
- glen: HTML already has a lot of this stuff
- 17:11:17 [ehlen]
- mihcael: builtins should not be hints; they should recognize what's specified or not
- 17:11:44 [Milan]
- s/michael/Milan
- 17:11:58 [burn]
- s/mihcael/Milan/
- 17:12:43 [Zakim]
- -Satish_Sampath
- 17:12:43 [ehlen]
- Robert: cool idea; but there is work missing here that should cause reluctance on including in spec
- 17:13:00 [burn]
- s/glen: this is a new/Milan: this is a new/
- 17:13:09 [ehlen]
- ... how would you autmote building a CFG off this pattern?
- 17:14:27 [ehlen]
- Milan: what about adopting two types: hints and grammars
- 17:15:03 [ehlen]
- michael: is it legal for speech engine to return something that doesn't fit the parameter
- 17:16:04 [ehlen]
- ... for a regex, if the engine returns a result that does not fit the pattern, what should happen?
- 17:16:39 [ehlen]
- ... provide some user-facing interface for correction?
- 17:16:47 [Zakim]
- -Dan_Burnett
- 17:16:51 [ehlen]
- ... nothing wrong w/ ahint that is ignored
- 17:16:59 [ehlen]
- s/ahint/a hint/
- 17:17:34 [Zakim]
- +Dan_Burnett
- 17:18:19 [ehlen]
- Milan: having things that need to be followed exactly, and then just hints
- 17:18:28 [ehlen]
- michael: was thinking everything is a hint
- 17:18:46 [ehlen]
- Milan: What if you just want a date and don't want to specify a grammar for it?
- 17:19:02 [ehlen]
- michael: if speech engine isn't up to the task, that's an issue w/ service
- 17:19:23 [ehlen]
- ... most engines should be smart enough to know what a date is. but do you say don't use speech if your engine can't do that?
- 17:19:28 [mbodell]
- s/michael/glen/
- 17:19:38 [ehlen]
- Milan: no, give error back
- 17:20:05 [ehlen]
- glen: date is a special case
- 17:20:13 [ehlen]
- Milan: but there are lots of those (bool, etc)
- 17:20:19 [mbodell]
- http://www.w3.org/TR/html5/the-input-element.html
- 17:20:30 [ehlen]
- glen: should we bind to every type of input element there is? automatic binding is questionable
- 17:20:51 [ehlen]
- Robert: if you need to click a mic to do it, what's the point of speech?
- 17:20:56 [ehlen]
- Charles: or handsfree cases
- 17:21:27 [ehlen]
- Milan: Developer has very complex UI. rather than re-write from scratch, it references a library
- 17:21:58 [ehlen]
- glen: take checkboxes. grammar would not be a binary, but the term bound to the box (e.g., "non-stop")
- 17:22:14 [mbodell]
- For date, look at http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-state
- 17:22:36 [mbodell]
- it lists that: If the element is mutable, the user agent should allow the user to change the date represented by its value, as obtained by parsing a date from it. User agents must not allow the user to set the value to a non-empty string that is not a valid date string. If the user agent provides a user interface for selecting a date, then the value must be set to a valid date string representing the user's selection. User agents should allow the user to
- 17:22:41 [ehlen]
- johnston: need to keep assistive use cases in mind
- 17:23:05 [ehlen]
- Charles: can use UI to highlight these things
- 17:23:13 [mbodell]
- so for input=date we should have the same ruling where it can't set it to values that are not valid date strings IMO
- 17:23:27 [ehlen]
- ... should be careful ruling things out in general
- 17:23:39 [ehlen]
- Charles: what is purpose of tag name here?
- 17:24:09 [ehlen]
- glen: if we decide to allow only a single type of input, then you don't need tag name. but here distinguishing what elemnt you're associating with
- 17:24:46 [ehlen]
- Charles: wouldn't it be redundant to put tag name here?
- 17:25:08 [ehlen]
- glen: no, complementary to binding. can use builting grammars w/ out any binding at all
- 17:25:41 [ehlen]
- ... but if the reco tag is bound to an element, then you'd create those default grammars automatically & assoc using the tag
- 17:25:54 [ehlen]
- Charles: how to know which builtin goes w/ which element?
- 17:26:31 [ehlen]
- glen: for multiple input fields and only one reco element, then you need to specify some grammars yourself
- 17:26:55 [ehlen]
- Charles: thought builtin would specify language-specific things, and binding would occur separately
- 17:27:50 [ehlen]
- Robert: couple questions on protocol draft
- 17:27:54 [ehlen]
- Should start w/ those next wee
- 17:27:56 [ehlen]
- week
- 17:28:01 [Zakim]
- -Glen_Shires
- 17:28:16 [Zakim]
- -Olli_Pettay
- 17:28:18 [Zakim]
- -Milan_Young
- 17:28:19 [Zakim]
- -Michael_Bodell
- 17:28:21 [Zakim]
- -Patrick_Ehlen
- 17:28:24 [Zakim]
- -Dan_Druta
- 17:28:26 [Zakim]
- -Robert_Brown
- 17:28:26 [Zakim]
- - +1.212.341.aacc
- 17:28:34 [Zakim]
- -Charles_Hemphill
- 17:29:42 [ddahl]
- zakim, bye
- 17:29:42 [Zakim]
- leaving. As of this point the attendees were Dan_Druta, Dan_Burnett, Michael_Bodell, Debbie_Dahl, Robert_Brown, Glen_Shires, Charles_Hemphill, +1.818.237.aaaa, Patrick_Ehlen,
- 17:29:42 [Zakim]
- Zakim has left #htmlspeech
- 17:29:45 [Zakim]
- ... Milan_Young, Olli_Pettay, Satish_Sampath, Michael_Johnston, +1.407.421.aabb, +1.212.341.aacc
- 17:30:08 [ddahl]
- s/+1.818.237.aaaa,//
- 17:30:45 [ddahl]
- s/+1.407.421.aabb,//
- 17:31:58 [ddahl]
- invite zakim #htmlspeech
- 17:32:08 [Zakim]
- Zakim has joined #htmlspeech
- 17:32:53 [ddahl]
- s/+1.212.237.aaaa,//
- 17:32:58 [ddahl]
- zakim,bye
- 17:32:58 [Zakim]
- Zakim has left #htmlspeech
- 17:33:06 [ddahl]
- zakim, bye
- 17:33:17 [ddahl]
- invite zakim #htmlspeech
- 17:33:34 [Zakim]
- Zakim has joined #htmlspeech
- 17:33:42 [ddahl]
- zakim, bye
- 17:33:42 [Zakim]
- Zakim has left #htmlspeech
- 17:35:42 [ddahl]
- present: Dan_Druta, Dan_Burnett, Michael_Bodell, Debbie_Dahl, Robert_Brown, Glen_Shires, Charles_Hemphill, Patrick_Ehlen, Milan_Young, Olli_Pettay, Salish_Sampath, Michael_Johnston
- 17:35:53 [ddahl]
- rrsagent, make logs public
- 17:36:08 [ddahl]
- rrsagent, draft minutes
- 17:36:08 [RRSAgent]
- I have made the request to generate http://www.w3.org/2011/10/20-htmlspeech-minutes.html ddahl
- 17:38:37 [ddahl]
- ddahl has left #htmlspeech
- 17:39:31 [burn2]
- burn2 has joined #htmlspeech
- 17:44:51 [burn2]
- zakim, who's here?