[voiceinteraction] minutes October 21, 2020

https://www.w3.org/2020/10/21-voiceinteraction-minutes.html

and below as text.

   [1]W3C

 

      [1] http://www.w3.org/

 

                               - DRAFT -

 

                   voice interaction community group

 

21 Oct 2020

 

Attendees

 

   Present

          debbie, jon, dirk

 

   Regrets

 

   Chair

          debbie

 

   Scribe

          ddahl

 

Contents

 

     * [2]Topics

         1. [3]IPA architecture 1.1 changes

     * [4]Summary of Action Items

     * [5]Summary of Resolutions

     __________________________________________________________

 

   <scribe> scribe: ddahl

 

IPA architecture 1.1 changes

 

   dirk: reviews minimum architecture

 

   jon: explain context in more detail

 

   dirk: could be use to follow up references

   ... dialogs are like apps

 

   debbie: difference between dialogs and dialog management

   ... dialogs are domain/application specific components that do

   a task

 

   dirk: where should a full-blown IPA be added?

 

   jon: should IPA also be in the blue box

   ... IPA should be in both boxes

 

   dirk: provider selection service could be just pure data

   ... another perspective is to just bypass the orange box

 

   debbie: is there room for standardization there? or just the

   green box to the blue box

 

   dirk: send and receive audio

   ... but if user deviates from specific application, what

   happens

   ... this would break the direct connection

 

   debbie: you would have to rely on the IPA to know when to give

   up

   ... if direct connection fails, what happens?

 

   dirk: then we would revert to the provider selection service

   ... need to have direct connection to hook in Google or Siri

   ... add IPA to other diagram and explain context box

 

   debbie: suggest captions for the figures

   ... also check for alt text

   ... should have noinput and error

   ... is the Dialog Manager responsible for the Dialog Strategy?

   ... or should a Dialog be able to choose its own Dialog

   Strategy?

   ... based on the application?

   ... like a travel planning dialog lends itself to a frame-based

   strategy

   ... could the DM have the ability to follow different

   strategies?

 

   dirk: yes, that would ease the developer's job

 

   debbie: the dialog would have to say what kind of dialog it was

   ... like a VoiceXML form

   ... one and done could be modeled with a degenerate state-based

   dialog

   ... is the DM just responsible for the UX?

   ... DM and Dialog both contribute to the UX

 

   dirk: DM defines the playground, but the Dialog implementation

   also is important

 

   debbie: we could think of components as black boxes or talk

   about internal structure

   ... maybe we should still think of them as black boxes

 

   dirk: just define interfaces

 

   debbie: we could give examples

   ... like VoiceXML as a dialog

 

   dirk: we should go one step further with this, more work on

   context, support for other IPA's, walkthrough for another IPA

   provider

 

   debbie: last thing to do is review use cases

   ... should review abstract and Introduction

 

   <scribe> ACTION: debbie to review intro material

 

   <scribe> ACTION: dirk update document based on today's

   discussion

 

   jon: will ask for review regarding context

 

   debbie: context is always there in diagrams, but often poorly

   defined

 

   jon: OVN will discuss next week

 

   dirk: also added table of abbreviations

 

   debbie: make sure to explain that NLG includes TTS as we use it

   here

 

   dirk: need to add IPA

 

   debbie: should eventually have references

 

Summary of Action Items

 

   [NEW] ACTION: debbie to review intro material

   [NEW] ACTION: dirk update document based on today's discussion

 

Summary of Resolutions

 

   [End of minutes]