[minutes] 21 April 2011

are available at http://www.w3.org/2005/Incubator/htmlspeech/2011/04/21-htmlspeech-minutes.html


For convenience, a text version follows.

Thanks to Olli Pettay for taking the minutes!

-- dan

******************************************************

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/0031.html

    See also: [3]IRC log

       [3] http://www.w3.org/2011/04/21-htmlspeech-irc

Attendees

    Present
           Dan_Burnett, Michael_Bodell, Olli_Pettay, Milan_Young,
           Bjorn_Bringert, Debbie_Dahl, Dan_Druta, Patrick_Ehlen,
           Charles_Hemphill, Robert_Brown

    Regrets
           Raj Tumuluri, Marc Schroeder

    Chair
           Dan Burnett

    Scribe
           Olli_Pettay

Contents

      * [4]Topics
          1. [5]f2f Logistics
          2. [6]updated "Final report" document
          3. [7]Determine if we already have other agreed-upon design
             decisions.
      * [8]Summary of Action Items
      _________________________________________________________

    <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:
    [9]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr/
    0031.html

       [9] 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
    [10]http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Apr
    /att-0028/HTMLSpeech.html

      [10] 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

Received on Tuesday, 26 April 2011 06:24:14 UTC