RE: Functional Requirements

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

I took Carol off the CC so we won't innundate her 
in a technical exchange.  If she wants this info, 
otoh, forward to her and let me know.

Here is a bit more grist.   The basic call/response paradigm 
of real time communication is similar across systems.
Basic event processing and real time response can be 
described as:

An event/message is received at a node.  

1.  Identify the node type (eg, is this a call for a service?)  

For example, display a drop down list of choices of events that can 
be received at this node.  List must have a description of each 
event type that aids selection.  User might enter partial or 
invalid information so system validates and can fill in default 
information for an event of that type.  It is possible that the 
event can only be partially identified so system provides a 
temporary or alias event type which is later rectified to the 
actual event type given more information.

2.  Create an event record (event code, systemID, details of 
event, current status) in the receiving system.

3.  Based on the selection of the event type, the event record 
is sent to a process/person/role node which handles events of that 
type.  

4  On receipt of this record, the record is rendered for 
use by the receiving node.  On receipt, the system can display 
options/procedures for use by the receiving node given the 
specifics for the received record (code plus details).  It 
can display other context information as well such as location 
of event.   On such a display, mapping technology is applied 
to enable the receiver to filter the displayed information, eg, 
the usable resources for the response.

5.  Received event codes are prioritized by type.  This priority 
can be overridden at the receiving node with appropriate authority, 
credentials, and the capability to select the reason for this action 
(traceability).  Given a current status, information such as the 
event progress is provided (eg, event complete, in-progress, etc). 
Status codes are used with appropriate defaults that can be overridden 
by the receiving node.

6.  Receiving node may need to elicit more information, so begins a 
series of call/responses to the sender.  For example, additional 
identification and description details:

o  Caller's name
o  Caller's location
o  Caller's phone number
o  Narrative
o  Descriptions of other objects at location of event, 
   their roles, their descriptive detail
o  How call is made (medium) 

This information must be recordable in any order received, 
is also code-driven where possible, and enables partial 
collection.

7.  Receiving node selects action type to respond.  Selects 
resources to be used for the response and schedules their 
use including the ability to set up a pattern of response 
(eg, recurring response by schedule or random initiation)

8.  Event information is made available to other systems 
not engaged in real time response, or in some cases, the 
receiving node acts only as a means to collect information 
and the actual selection of response is delegated to a 
different node.   

9  Feedback and update is incorporated to enable information 
gathered in real time to be corrected.

Essentially, the process is similar or recursive among most 
communication node types in a system of communicating nodes.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]

Thanks,

I will see to it that we add this strawman set of tasks to the lists 
we will be drawing up since they accord with my own set in many 
respects as regards the language itself in terms of offering ways to 
structure data as human contextual information.