<burn> trackbot, start telcon

<trackbot> Date: 14 April 2011

<burn> Scribe: Milan Young

<burn> ScribeNick: Milan_Young

<burn> Agenda: 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: 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 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

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Milan Young
Found ScribeNick: Milan_Young
Default 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
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
Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/0017.html
Found Date: 14 Apr 2011
Guessing minutes URL: http://www.w3.org/2011/04/14-htmlspeech-minutes.html
People with action items: