- From: Dan Burnett <dburnett@voxeo.com>
- Date: Thu, 10 Nov 2011 15:37:48 -0500
- To: public-xg-htmlspeech@w3.org
Group, The minutes from today's call are available at http://www.w3.org/2011/11/10-htmlspeech-minutes.html For convenience, a text version is embedded below. Thanks to Patrick Ehlen for taking the minutes. -- dan ********************************************************************************** HTML Speech Incubator Group Teleconference 10 Nov 2011 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Nov/0058.html See also: [3]IRC log [3] http://www.w3.org/2011/11/10-htmlspeech-irc Attendees Present Dan_Burnett, Dan_Druta, Glen_Shires, Olli_Pettay, Michael_Bodell, Debbie_Dahl, Patrick_Ehlen, Charles_Hemphill, Satish_Sampath, Michael_Johnston, Avery_Bishop Regrets Chair Dan_Burnett Scribe Patrick_Ehlen Contents * [4]Topics 1. [5]Review of updated final report draft 2. [6]Issue 1 3. [7]Moving explanation of "final" to end of section 4. [8]Protocol issue 3 5. [9]API issue 3: Updated re-reco example to use Robert's new version 6. [10]API issue 4: Wrote up the EMMA mappings. This involved a new section explaining the mappings and an example to illustrate it 7. [11]API Issue 5: Brought back the grammar/parameter functions. This involved uncommenting the functions/explanations, adding a new one for grammarString, and renaming and rewording appropriately. * [12]Summary of Action Items _________________________________________________________ Review of updated final report draft <burn> Report draft is in this email: [14]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Nov /0061.html [14] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Nov/0061.html Dan: Manually merged changes instead of applying add'l edits Issue 1 Issue 1 Michael: Change in IDL in sec 7.1.4. resultDeleted event ... There's also an event for this (SpeechInputResultDeleted). <mbodell> link to the section with most of the changes: [15]http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-html speech.html#speechinputrequest-section [15] http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-htmlspeech.html#speechinputrequest-section Moving explanation of "final" to end of section Protocol issue 3 Added Result-Index header field burn: changes are in a few different places; 1st in reco headers section. ... now adds a # of 1-20 digits, and added a description API issue 3: Updated re-reco example to use Robert's new version all agree example looks good <mbodell> Link to new section on EMMA mappings: [16]http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-html speech.html#emma-to-interpretation [16] http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-htmlspeech.html#emma-to-interpretation API issue 4: Wrote up the EMMA mappings. This involved a new section explaining the mappings and an example to illustrate it michael: explains mapping section and example added ... in section 7.1.5 <burn> this should be a static dated version of the current doc: [17]http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-html speech-20111110.html [17] http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-htmlspeech-20111110.html smaug: Specify whether all the emma namespace stuff in emma spec is required <mbodell> link to emma element: [18]http://www.w3.org/TR/emma/#s3.1 [18] http://www.w3.org/TR/emma/#s3.1 can probably do just emma specification but leave out location and xsi ddahl1: does not appear to be required charles: looks like xmlns:emma only can be used ddahl1: and the emma:emma version michael will drop the 3 lines assoc. with xsi stuff API Issue 5: Brought back the grammar/parameter functions. This involved uncommenting the functions/explanations, adding a new one for grammarString, and renaming and rewording appropriately. <mbodell> Back to [19]http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-html speech.html#speechinputrequest-section [19] http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-htmlspeech.html#speechinputrequest-section Brought back some of the API grammar functions satish: seems fine burn: On issue 5, there was another resolution on built-in default; still needs to be done? mbodell: yes satish: needs array manipulation funcs? burn: better to leave the way it is now; can revisit delete capability later on smaug: misleading names on 7.1.4.2 e.g., "Speech Input Request" (w/ spaces) mbodell will do that Topic; API Issue 6: Shortend the naming of resultEMMAXML and resultEMMAText to no longer have the result. They would nearly always be referenced from result property anyways so this just changes result.resultEMMAText to result.EMMAText) no objections <glen> Add clarification at end of description of AddGrammarElement method. "Note that grammars can be removed through direct maniplulation of the grammar array." API Issue 10: Added text property to TTS with explanation and also included statement about xml:lang <mbodell> See section: [20]http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-html speech.html#tts-section [20] http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-htmlspeech.html#tts-section no requests for changes around text attribute burn: Section 7.1.3 language ... language on "should use base64 encoding" is ambiguous ... people can probably figure out when they need to use base64 in UA ... those are all of the changes that have been applied so far ... will have more time in next few days to work on it ... practical issue: last date for call is next week ... we could (a) end call now and make more changes; or (b) try to do them live now during the call ... could also describe how everything gets done and reviewed MichaelJ: discussed EMMA mapping yet? <mbodell> e,,a at [21]http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-html speech.html#emma-to-interpretation [21] http://www.w3.org/2005/Incubator/htmlspeech/finalreport/XGR-htmlspeech.html#emma-to-interpretation MichaelJ: wasn't sure about "Boston flight 311" and then interpretation being "Boston"; could probably come up with more clear string->meaning mapping ... What is assumption on what ends up in interpretation? ... So a DOM object is hanging off interpretation? mbodell: is "any"; could be EMMA literal, or XML DOM document ... it's all javascript MichaelJ: Other case is where it's a JSON payload; so interpretation would contain JSON? mbodell: didn't have any mapping for that; only literals and xml MichaelJ: so we may want to consider having JSON within literal in CDATA mbodell: not CDATA; just a string <Michael> <emma:literal><![CDATA[ {_cmd:"CALL",_obj:"joe_bloggs"}]]></emma:literal> mbodell: these will be normal javascript properties ... based on what's there, if you have emma:literal, you just get a string with that value MichaelJ: but there are attribs in EMMA 1.0 that describe what type of data you have mbodell: if you want to eval your content, you can do it in javascript MichaelJ: that's reasonable. could modify this down the line, but you can always eval or parse it <mbodell> For context the description of sting literal in emma is: [22]http://www.w3.org/TR/emma/#s3.5 [22] http://www.w3.org/TR/emma/#s3.5 burn: open again for use of remaining time ddahl1: is there a deadline for sending comments to list, and how should time be allocated in general? burn: editing references can wait until end (or even after) ... if anyone had updates for examples, send them to list ... a few other issues that require more substantive text: ... such as text around issue 11 on bindings ... understand that more work needs to happen here and there are gotchas 11, 17, 18 related mbodell will take a crack at that burn: michael was also going to take issue 10 Michael will also do 23 22 still needs to be done burn will do 22 mbodell already did 10 burn: 8 and 13 are on switching to collections from arrays ... good example from Satish on making it look like FileList MichaelJ: sent example w/ literal w/ semantics burn: aligning adjustment of requirements burn will take that one burn: how do we wrap up effectively? <Avery> Sorry I'm late burn: can contentful changes be done by, say, tuesday? ... gives time for review by thursday ... other option is a very slight extension to beginning of december mbodell: let's just aim to get content in by tuesday ... other changes can go over email burn: would prefer that as well ... sounds like it's just a matter of getting those changes in ... next and final call is in one week <Avery> I might be able to make it Thursday
Received on Thursday, 10 November 2011 20:38:28 UTC