HTML Speech Incubator Group Teleconference -- 21 Apr 2011

<burn> trackbot, start telcon

<trackbot> Date: 21 April 2011

there is some echo

<burn> Scribe: Dan Druta

<Robert> microphone problems...

<Robert> I'm goign to call in again... :/

<Robert> mea culpa :$

<burn> Scribe: Oll_Pettay

<burn> ScribeNick: smaug_

<burn> Scribe: Olli_Pettay

<burn> Agenda: http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/0031.html

f2f Logistics

bringert: everyone should have got email about the hotel booking
... if you have not got the email, let me know

updated "Final report" document

<burn> document is at http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/att-0028/HTMLSpeech.html

burn: are there any concerns how I worded section 3.3?

Determine if we already have other agreed-upon design decisions.

bringert: it seems that SGRS should be the only mandated grammar format

Robert: XML format of SRGS

oops

thanks ddahl

<Milan_Young> Dan: clairified that "mandate" means something that will be required of all (conforming) implementations. Implementations can always go further.

bringert: are there any other formats than SSML for TTS which should be supported?
... like plain text?

burn: yes, I'd like to support UTF-8 text
... i18n group may have opinion on that

bringert: I propose SRGS 1.0 and SSML 1.1

burn: I think this is fine for now
... we need to require SRGS 1.0

<Milan_Young> Milan: require SISR 1.0

<burn> group: general agreement

bringert: a topic we may not agree is the fallback
... whether we require everything to be supported consistently and how to handle not supported features
... I'd like to make sure the focus is on to let web developers to do new things

<ddahl> +1 to reversing the order of the paragraphs in the context section

burn: any other comments about Dan's overview paragraph?
... we can continue on email list on that

bringert: one thing to think about; whether ASR and TTS APIs should be separate

Robert: we included them in the same spec.

Michael_Bodell: there may be similar parameters, and features like barge-in may require them to be coupled

bringert: does MS think that we need a separate methods for barge-in?

Robert: that is unclear

Michael_Bodell: we don't see any strong reasons for shared API, though not for non-shared API either

Robert: in our API for example error handling is shared

bringert: it might be good to have two simple APIs

Robert: there clearly will be two different objects for ASR/TTS
... if we agree on loose coupling, that is probably ok

bringert: I think better to share as little as possible
... could we agree that both ASR and TTS should be separately implementable?
... and useable
... it shouldn't be impossible to implement either one without the other one
... another issue is that whether the details of the protocol between UA and engine should be visible ?

Milan_Young: in case like Sathish's proposal using websocket, webapp would see the protocol

bringert: but what about MS' or Mozilla's proposal
... keeping the protocol details hidden allows UA/engines to use better protocols in the future

burn: there is clearly more to discuss on this
... " how much of the detail of the protocol should be visible in the API or WebApp"

bringert: about consistent ux. there should be reasonable fallbacks
... I think fallback applies only to default engine

Milan_Young: webapp developer should have consistent functionality

ddahl: they are two separate topics, consistent end user experience and consistent developer experience

Milan_Young: it would be nice to say that you have the same experience if you use the same engines across the browsers

bringert: might not be possible because of microphones etc
... I'm talking about how we should design the API, not about Dan's summary

<ddahl> we should have the goal of making the end user experience as consistent as possible across browsers, but there are things that are out of our control, like recognizer accuracy.

<Milan_Young> Milan: Goals: 1) Consistent as possilbe user experience 2) Consistent programming model when using default engine 3) Identical experience when using same engine

bringert: I'd like to have a list where web apps could rely on certain things, expect like supported languages etc.
... so we could guarantee that the fallback is similar
... I'd like to list where the outcome can be different

ddahl: it would be good exercise to enumerate such features

Milan_Young: there was a different approach
... small set of mandatory supported things

bringert: but this allows things outside the mandatory set
... browsers have all sorts of extensions to standards (CSS, elements, etc)
... so we agree that there should be small mandatory set, but not that one could use other features?

<burn> for the minutes: disagreement on the mechanism for using capabilities outside of mandated interoperable set

<burn> ... and on where (default engine, remote engine, or both) you can

<Milan_Young> Milan: custom grammars would be prefixed with an x for example

bringert: for each feature we need to say how the extensions and fallbacks work
... productive way could be to enumerate the features which may need extensions and/or fallbacks

burn: even for SSML this was a big discussion topic

bringert: concrete example: I have a speech app which want to handle certain language. I'd like to fail if the language isn't supported

Dan_D: maybe good way to look at this is to list configurable features

Michael_Bodell: shepazu sent email about CSS 3 Speech

bringert: CSS is only about synthesis?

burn: yes

- DRAFT -

HTML Speech Incubator Group Teleconference

21 Apr 2011

Attendees

Contents

f2f Logistics

updated "Final report" document

Determine if we already have other agreed-upon design decisions.

Summary of Action Items

Scribe.perl diagnostic output