W3C home > Mailing lists > Public > public-xg-htmlspeech@w3.org > December 2010

[minutes] 9 December 2010

From: Dan Burnett <dburnett@voxeo.com>
Date: Tue, 14 Dec 2010 06:45:07 -0500
Message-Id: <C10A897A-5C96-43B5-86DE-BEEABD30FE59@voxeo.com>
To: public-xg-htmlspeech@w3.org
Draft minutes are available at http://www.w3.org/2010/12/09-htmlspeech-minutes.html 

Please let me know if any corrections or additions are needed.

For your convenience, a text version of the minutes follows.

-- dan

               HTML Speech Incubator Group Teleconference

09 Dec 2010


       [2] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0069.html

    See also: [3]IRC log

       [3] http://www.w3.org/2010/12/09-htmlspeech-irc


           Michael_Bodell, Olli_Pettay, Dan_Burnett, Robert_Brown,
           Milan_Young, Debbie_Dahl, Dan_Druta, Satish_Sampath,

           Dan Burnett



      * [4]Topics
          1. [5]Minutes from last call
          2. [6]new version of the req draft
          3. [7]R34 -
          4. [8]R32 -
          5. [9]R19 -
          6. [10]R11 -
          7. [11]R09
          8. [12]R13
          9. [13]R23
         10. [14]UA/SS -
      * [15]Summary of Action Items

    <burn> trackbot, start telcon

    <trackbot> Date: 09 December 2010

    <burn> Scribe: Dan_Druta

    <burn> ScribeNick: DanD

    <burn> Agenda:

      [16] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0069.html

Minutes from last call

    burn: There were some issues with the minutes

    mbodell: I think I captured them

    <burn> Dan's followup email about the minutes:

      [17] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0071.html

    burn: No need to update the minutes

new version of the req draft

    <burn> Draft is:

      [18] http://www.w3.org/2005/Incubator/htmlspeech/live/draft-20101209-requirements.html

    burn: No issues with the requirements draft

R34 -

      [19] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0064.html

    mbodell: Threre is consensus
    ... drop R34

    <burn> nick Robert is Robert_Brown

R32 -

      [20] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0067.html

    mbodell: consesnus to keep it

R19 -

      [21] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0068.html

    mbodell - Consensus to drop - out of scope

R11 -

      [22] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0065.html

    <burn> DanB proposes (instead of Bjorn's wording): "The User Agent
    and protocol must not prevent web applications from integrating
    input from multiple modalities."

    burn: New wording proposed

    ddahl: concern includes the API in the protocol

    <burn> possible adjustment to: "Web applications must not be
    prevented from integrating input from multiple modalities"

    <burn> agreement/disagreement?

    ddahl: OK with the wording

    <satish> I got dropped, having difficulty joining in.. will keep

    burn: we got consensus on the wording


      [23] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0060.html

    mbodell: There are a few comments

    <mbodell> bjorn's proposed requirements: 1. The web app should be
    notified when TTS playback starts.

    <mbodell> 2. The web app should be notified when TTS playback

    <mbodell> 3. The web app should be notified when the audio
    corresponding to a TTS <mark> element is played back.

    burn: I agree with the 3 proposed requirements

    ddahl: we can always add later

    <burn> olli also agrees and notes that we might want to add more

    Robert: Agreed

    burn: on the long email we need to decide how to wording
    ... if you look at SSML 1.1 it will be nice to receive a
    ... the decision we got so far should be sufficient if we agree and
    we can add later

    ddahl: if we look at less used events we can spend a lot of time

    burn: no disagreements


      [24] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0066.html

    mbodell: there was quite a conversation about this one

    burn: we can't know all the security threats are going to be

    <bringert> trying to join, getting "all circuits are busy now"

    <bringert> trying french number

    <burn> DanD: want to separate notification from communication

    <bringert> french number worked

    <burn> ddahl: does communication mean http/html?

    <burn> bringert: customization is great but can have security

    bringert: we pretty much agreed but it's hard to word it

    ddahl: would it be possible to relate to other requirements?

    bringert: we should allow customisation unless it violates other
    requirements in this requirements

    burn: unless it violates other requirements in this doc

    ddahl: than we need to make it clear what req
    ... we get into maintenance problems

    bringert: typing the wording for review

    <mbodell> security requirements: 10, 16, 17, and 18

    burn: we can be specific and miss or be vague and open

    <burn> michael: we should be specific about what we know now and
    include a clause that covers the future

    <bringert> "Web apps should be able to customize all aspects of the
    user interface for speech recognition, except where such
    customizations conflict with security and privacy requirements in
    this document, or where they cause other security or privacy

    ddahl: we create a spec and it gets implemented and a security
    problem comes up. Are we not compliant?

    <mbodell> can/should we list which are the "security and privacy
    requirements in this document". I think 10, 16, 17, and 18 but do
    others agree or notice others?

    <bringert> FPR1

    dand: we should be specific where it's clear and leave an open
    window for unknown

    bringert: Michael already listed the requirements

    <bringert> maybe FPR20

    <bringert> "The spec should not unnecessarily restrict the UA's
    choice in privacy policy."

    bringert: 1, 10, 16, 17, 18 and 20 apply

    <mbodell> so our list to date is 1, 10, 16, 17, 18, and 20

    mbodell: we should use the statement with the list of requirements
    ... we got consensus on that


      [25] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0038.html

    bringert: Hard to follow all the comments in the email
    ... we should continue and ask if there's an actual requirement
    ... We tend to agree that we can do with the API's for multimodal

    mbodell: Our current req in the doc and the existing API's are

    <mbodell> I think the agreement is that our current requirements for
    Speech XG + existing html is sufficient to do multimodal

    <mbodell> and that closes r23


      [26] http://lists.w3.org/Archives/Public/public-xg-htmlspeech/2010Dec/0062.html

    mbodell: this is getting a little bit away from requirements

    bringert: it is valuable to discuss

    Milan: As long as it's possible for the web app to talk with the
    speech service we shoud be fine

    Robert: we need to get back on topic - Standard protocol

    mbodell: we have requirements to address this

    bringert: one standard protocol was required if we go thru the

    Robert: how do evaluate Satish's proposal

    Milan: if we can't access the audio and we have to do it thru the
    browser we need a common protocol

    mbodell: we should not drop any requirements, evaluate the email
    conversation and determine if we need additional req

    Milan: They should work consistently in all browsers

    mbodell: we already have a lot of req that we need to go back to

    Milan: Can we have an update on the audio standards?

    bringert: DAP is in early phases and we shoudl provide input to them

    <smaug_> DAP is not Device API

    <burn> smaug_, please explain

    burn: there are several streaming protocols

    <ddahl> there is a Media Capture spec published by the W3C DAP group
    that we might want to look at [27]http://dev.w3.org/2009/dap/camera/

      [27] http://dev.w3.org/2009/dap/camera/

    Milan: how time sensitive is this?

    <burn> smaug_, so you mean that the work of the W3C Device API WG
    (group name called "DAP") is not the same as the Device API work in
    the WHATWG

    bringert: we should start working with other groups and experiment

    Robert: we need to determine what are our audio requirements

    bringert: it should be web app to speech service requirement

    <ddahl> there's also a Media Capture API
    [28]http://www.w3.org/TR/media-capture-api/, I'm not sure what the
    relationship is

      [28] http://www.w3.org/TR/media-capture-api/

    mbodell: this is in conflict with requirements FPR30 and FPR31

    Milan: let's modify Robert's req about the codec

    mbodell: are there any req missing?
    ... are there any req that we havent talked and agreed on

    burn: this week we need to close in any additional req
    ... Req 12 is agreed on
    ... based on lack of comments in email

    mbodell: there was an action for me

    burn: there was a request to write text to those requirements that
    don't have any description

    mbodell: I'm a little bit nervous about writing text other than what
    was agreed in minutes and email

    burn: I agree with Michael to be concerned about the wording
    ... the next step is to get in more detail and come with proposals
    ... wording might change

    mbodell: some are self explanatory
    ... description should come part of the prioritazation

    burn: if there are any missing req send them until next week

    bringert: can we have a clean version of the requirements?

    burn: Michael will clean up

Summary of Action Items

    [End of minutes]
Received on Tuesday, 14 December 2010 11:45:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:48 UTC