- 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