Meeting minutes
look at minutes from last time https://
debbie: didn't update the text description ACTION: debbie to update text description in Section 4
Action: dirk to change arrows to reflect the primary use case
dirk: didn't do that
Action: debbie to pull together list of outstanding comments
debbie: did do that
debbie: here's the link to github issues https://
dirk: how to track issues?
dirk: should we track in the minutes as well as github?
debbie: no point in the minutes, so just use GitHub
dirk: we can use some labels like "projects" that map to documents, "milestones" for the next version to publish
dirk: version tracking?
dirk: use this to track actions
dirk: what is the audience for the document?
debbie: application developers, platform developers, anyone else?
jim: add the reason why this audience should be interested?
dirk: yes
jim: one reason is that it could provide insight into future platforms
jim: who else?
debbie: buyers of conversational agents
dirk: offerers of conversational agents
jon: coders, e.g. open source, also secondarily, purchasers, and the third would be legislators and regulators -- what are best practices
… what are tradeoffs in control
dirk: also platform architects is another primary group
… there is a big difference between developers and architects
this is issue 2
jon: can do this and update document in GitHub
Action: make sure jon has access to GitHub
issue 3: what is the problem?
debbie: interoperability
dirk: identify components that contribute to an IPA
debbie: that's a prerequisite to interoperability
debbie: some of partitioning is tradition
… it's consistent from most existing technology
jim: similar issues to voice registry system
jon: could say publicly that VRS is under development by OVN
jim: some principles -- Single Responsibility Loose Coupling Event-Driven Availability and Partitioning of Network Eventual Consistency Interface segregation Automation (CICD, DevOps, Containerization, Service Mesh, Observability, etc.)
… from the OVN
debbie: what is eventual consistency?
jim: eventually components will be consistent
debbie: what is "interface segregation"?
jim: not sure
debbie: what is "service mesh"?
jim: each module is subject to automation
dirk: "interface segregation" interfaces should not be forced to depend on interfaces that they do not use
dirk: will add something about software principles
debbie: could talk about interoperability
jon: purpose of document is to define components and interoperability
issue4
jim: Travel Planning seems to be specialized
debbie: I was thinking that it was both
jim: there could be a continuum
jon: independent vs. developed by a platform
jim: this is for informational purposes for the reader
… we don't need to do anything for the document
jon: I think this is an architecture beyond the platform, if you're just developing a skill you don't need this
issue5
debbie: agree with the last three points
dirk: agree with the second and third
… if we move ASR and TTS to the client it may confuse architects
jim: ASR and TTS are closely tied to input/output devices
dirk: the components are related to each other, but this doesn't match current practice
… very little local ASR
… but conceptually it makes sense
jim: should we just concentrate on the conceptual in Figure 1
dirk: we can move these components to the client and say that this is a conceptual view
… what about NLU and NLG
jim: do we have a deadline?
dirk: there are lots of issues, say two months
debbie: we could work on things off-line before the next call
the next call will be in two weeks, April 21