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?