[voiceinteraction] some requirements derived from the Architecture document

During the last call I said that I would pull out some implied requirements from the architecture document
(https://w3c.github.io/voiceinteraction/voice%20interaction%20drafts/paArchitecture-1-2.htm)
I got through the IPA Client and thought what I came up with was worth discussing in the call today. They're noted with the sections
that they came from.

The MUST, MAY, SHOULD language  for requirements is defined in https://www.ietf.org/rfc/rfc2119.txt.

Implied Architecture Requirements
1
Intelligent Personal Assistants (IPA's) MUST be able to provide general purpose information
Specialized virtual assistants MUST be able to provide enterprise-specific information
IPA's SHOULD be able to perform transactions
Specialized assistants MUST be able to interoperate with general IPA's
IPA's SHOULD be able to execute operations in a user's environment
IPA's MUST be able to interact with users through voice or text (language?) or both.

2.1.1
IPA's MUST be able to transfer a partially completed task to another IPA

3.0
The architecture SHOULD support question answering and information retrieval applications
The architecture SHOULD support executing local services to accomplish tasks
The architecture SHOULD support executing remote services to accomplish tasks
The architecture MUST support dynamically adding local and remote services or knowledge sources.
It MUST be possible to forward requests from one IPA to another with the same architecture
It MUST be possible to forward requests from one IPA to another with the same architecture, omitting the client layer
IPA extensions MAY be selected from a standardized marketplace
IPA's MUST include a Client layer
IPA's MUST include a Dialog layer
IPA's MAY include an API/Data layer
Components MAY be shifted to other layers as needed

3.1 
The Client layer MAY include a microphone
The Client layer MAY include a speaker
Additional (non-speech) output modalities MAY be employed to render output

3.1.3

The client MUST be activated by means of a Client Activation Strategy.
As an extension IPA Clients MAY also capture input via text and output text.
As an extension IPA Clients MAY also capture input from a specific modality recognizer.
As an extension IPA Clients MAY also capture contextual information, e.g. location, that it obtains from Local Data Providers.
As an extension an IPA Client MAY also receive commands to be executed locally in the Local Services.
As an extension an IPA Client MAY also receive multimodal output to be rendered by a respective modality synthesizer.
IPA Clients MAY reference a session identifier.

3.2.2.1
The IPA Client MUST be activated with a Client Activation Strategy
The Client Activation Strategy MAY be push-to-talk
The Client Activation Strategy MAY be hotword
The Client Activation Strategy MAY be a change in environment
The Client Activation Strategy MAY be a different strategy not enumerated here

3.2.2.2
The IPA Client MUST include a Local Service Registry
The Local Service Registry MUST maintain a list of Local Services
The Local Service Registry MUST maintain a list of Local Data Providers

3.2 Dialog Layer

tbd

3.3 API's/Data Layer

tbd

Received on Wednesday, 10 August 2022 14:21:48 UTC