[minutes] telecon 14 April 2011

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:04:11 UTC