W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > April 2011

Re: [minutes] telecon 14 April 2011

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 14 Apr 2011 14:51:33 -0400
Cc: public-xg-htmlspeech@w3.org
Message-Id: <C3948ACE-BBF0-49D9-862B-32D43A6438D4@voxeo.com>
To: Dan Burnett <dburnett@voxeo.com>
Raj had also sent his regrets as well.

On Apr 14, 2011, at 2:03 PM, Dan Burnett wrote:

> Thanks to Milan for taking the minutes!  They can be found online at http://www.w3.org/2011/04/14-htmlspeech-minutes.html 
> .
>
> For convenience, a text version follows.
>
> -- dan
>
>
> ===============================================
> Attendees
>
>   Present
>          Michael_Bodell, Dan_Burnett, Marc_Schroeder, Robert_Brown,
>          +1.425.391.aaaa, Rania_Elnaggar, Dan_Druta, Milan_Young,
>          Bjorn_Bringert, Debbie_Dahl, +1.425.830.aabb,
>          Charles_Hemphill, Michael_Johnston
>
>   Regrets
>          Jerry_Carter, Olli_Pettay
>
>   Chair
>          Dan Burnett
>
>   Scribe
>          Milan Young
>
> Contents
>
>     * [4]Topics
>         1. [5]F2F logistics
>         2. [6]Final report document produced by Dan
>     * [7]Summary of Action Items
>     _________________________________________________________
>
>   <burn> trackbot, start telcon
>
>   <trackbot> Date: 14 April 2011
>
>   <burn> Scribe: Milan Young
>
>   <burn> ScribeNick: Milan_Young
>
>   <burn> Agenda:
>   [8]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/
>   0017.html
>
>      [8] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/0017.html
>
> F2F logistics
>
>   Bjorn: Has sent list to admin
>   ... If haven't filled out survey, need to let me know
>
>   Dan: Local transportation?
>
>   Bjorn: Details comming soon
>
> Final report document produced by Dan
>
>   Dan: Purpose is to provide placeholders
>   ... Want to capture essentials about design that go beyond
>   requirements
>   ... This document would survive if we decide not to recharter
>   ... first decision that has been made is in regards to the three
>   "aspects"
>   ... questions on structure of document?
>
>   <none>
>
>   scribe: discuss Milan's recent email about document
>
>   <burn> Milan's email:
>   [9]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/
>   0018.html
>
>      [9] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/0018.html
>
>   Dan: Agree that we should not call them components, aspects is
>   better
>   ... Second point was whether we had come to agreement on defining
>   three aspects
>
>   Milan: I don't know enough about HTML to know if markup is always
>   needed for Javascript API
>
>   Bjorn: aspects are OK, we can always change our mind
>
>   Dan: Purpose is to have something to iterate over
>
>   Marc: Aspects might be a good place to break down between v1 and v2
>
>   Dan: These are real agreements of the group
>
>   Bjorn: We agree that we need to address these points (in agreement
>   section), and that this document must specify how they are handled
>
>   Dan: These agreements are similar to an IETF "archtiecture document"
>   ... Point is to capture concrete decisions about what we must do
>
>   <burn> The document we are discussing is at
>   [10]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr
>   /att-0016/HTMLSpeech.html
>
>     [10] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/att-0016/HTMLSpeech.html
>
>   DanD: Last call brought up point about preference and user consent
>   ... Also want to discuss my "archtiecture" email
>   ... Might be useful in framing discussion
>
>   Dan: Terminology is a great idea
>
>   Bjorn: Might add a glossary
>
>   Dan: Diagram can take a long time to come to agreement
>
>   DanD: Diagram will be what words will capture, not the other way
>   around
>
>   Robert: Diagram is a distraction
>   ... Let's work on the list of terms first, and then build a diagram
>
>   DanD: That's fine, just wanted to start discussion
>
>   Bjorn: All proposals use a script API to control recognition
>
>   Dan: Not every feature is solved with script
>
>   Bjorn: All features of speech API must be accesible by ECMA
>
>   Dan: Accessible?
>   ... there are place where you might attach handlers, but still using
>   the HTML structure
>
>   Bjron: HTML blurs line between markup and script
>   ... meant HTML5
>
>   Bjorn: ECMA is a complete API, markup may feed back into that
>
>   Michael: Hard to define where service fits into all of this
>
>   DanD: Maybe we need to define who script is targeted at
>   ... to whom the script is targeted :)
>
>   Bjorn: We all talking ECMA
>
>   MichaelJ: How to bring together graphical content with speech
>
>   Dan: That is more a statement about the purpose of the group
>
>   Bjorn: The entire API must be useable in Javascript
>
>   Dan: I'll put in some strawman language after the call
>
>   Charles: Would like a high-level statement
>
>   Milan: Already have misssion statement and requirements.
>
>   Charles: Not sure those agree. Where is the purpose?
>
>   Dan: Maybe we should add a summary which captures the design biases
>   ... Need more context
>   ... Could others suggest some text?
>   ... Looking for a rational
>
>   DanD: I'll take a cut
>
>   Dan: I gave a similar response last week on differences between
>   VoiceXML
>
>   Bjorn: Notifications from user agent should be in the form of
>   Javascript events
>
>   Robert: Bubling is unclear
>
>   Bjorn: That's markup not javascript
>   ... More agreement, 1) start input 2) stop input 3) cancel input
>   ... stop and cancel might be blured by Mozialla
>
>   MichaelJ: Need seperation between stop and cancel
>
>   Bjorn: Cancel stops speech input without a result
>   ... all propsals had an onspeechstart event
>   ... and all had an onspeechend
>   ... all had onerror. Unclear whether nomatch and noinput mapped to
>   errros
>   ... and when recresult was availible
>   ... all can specify grammars
>
>   Dan: Regarding onspeechend, what does end of speech mean?
>   ... this is in regards to the endpointer
>
>   Bjorn: most useful is when endpointer finished
>
>   Milan: Need to consider dictation
>
>   Michael: Parameters would dictate meaning of of endofspeech event
>
>   Bjorn: Onspeechstart is also a function of endpointer
>
>   MichaelJ: Need to flag that implementations will vary around this
>   point
>
>   Robert: On mobile, "cheap
>   ... endpointing on client may be necessary
>
>   Dan: Will add this as a topic for discussion
>
>   Michael: Play and pause for TTS
>   ... are also points of agreement
>
>   Dan: probably also have a stop
>
>   Bjorn: Google has a way to effective issue a stop, but no explicit
>   method for it
>
>   DanD: Thought we had an agreement to allow web app to specify speech
>   engine
>
>   Bjorn: Would suggest that it could be specified by URI
>   ... Ollie suggested that this be a v2
>   ... I'm OK in a v1 as long as they are lightwieght
>   ... as *mechanism* is lightweight
>   ... Disagreement that it should be referenced by URI?
>
>   Michael: That sounds sufficiently flexible
>
>   Dan: OK as long as we don't mean http: URL
>   ... W3C tends not to like URNs
>
>   Bjorn: We would need to restrict content of URIs so that solution
>   could interoperate
>
>   Dan: Difference between configuration and accessibility
>
>   Bjorn: Might not work in open web model
>
>   Dan: General config of language tags to URIs
>   ... Selecting speech service implementation by URI
>
>   MichaelJ: Need ability to do this by URI
>
>   Dan: Speech services implementations must be referenceable by URI
>
>   Bjorn: Another agrement: Must be possible to refererence a gramamr
>   by URI
>   ... also that could reference language by language tag
>
>   Dan: Might be useful to have a means of specifying a list of
>   language tags
>
>   Michael: Should claify that you don't need to specify grammar
>
>   Dan: should clairify that behavior in such cases is not specified
>
>   Milan: Can we limit this list to a v1?
>
>   Micahel: This is all implicitly v1
>
>   Dan: This is a statement of how things should be done when they are
>   done
>   ... Next step is to capture this in the document
>   ... can review over email
>
>   Michael: It would be useful to pull in use cases into that document
>
>   Dan: OK, Michael will take first
>   ... cut on that
>
>
Received on Thursday, 14 April 2011 18:52:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 April 2011 18:52:02 GMT