Issues for Mailing list of the Alerts Management Service 1.0 (ALMAS) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 12287: Section 2.1
Issue 12288: 2.2 Conformance requirements
Issue 12289: 2.3.1 ALMAS Client Callbacks
Issue 12290: 2.3 General
Issue 12291: Section 2.3.1 & 2 Section 2.3.2.1
Issue 12292: Section 2.3.2.1
Issue 12293: 2.3.2.1
Issue 12294: 2.3.2.3 AlertDataExtraAttributes
Issue 12295: 2.3.2.8 DataTag
Issue 12296: 2.3.3.1.1 ReceiverKind Operations
Issue 12986: ALMAS Template Alert Data specification schema - Current schema only allows one Alert Template per XML file
Issue 12987: Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length"
Issue 12988: ALMAS DCOM IDL corrections: Sections 2.8.11 & 2.8.1.3 Section 2.8.1.3
Issue 12989: Section 2.8.1.3
Issue 12990: Sections 2.6.1.2 & 2.8.1.2 - Inconsistent naming of the Call Status parameter Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides Section 2.6.1.1 ALMAS_DataModel.idl
Issue 12991: Section 2.6.1.3, 2.3.3.5.1 & 2.7.4.2 Method RaiseAlertFromOverrides Section 2.6.1.1 ALMAS_DataModel.idl
Issue 12992: Section 2.6.1.1 ALMAS_DataModel.idl
Issue 12993: Sections 2.6.1.3, 2.7.4.2, 2.8.1.3
Issue 12994: 2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs
Issue 13013: ALMAS configuration files contain not valid xsd constructs
Issue 13014: Method GetAllTemplateIDs of ALMASManager not mapped
Issue 13015: Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides)
Issue 13016: priority attribute value
Issue 13017: Attribute TimeoutAction
Issue 13018: ALMASReceiver.stateChangeNotification(int, Enumeration)
Issue 13019: Catgorisation rules
Issue 13020: DynamicMessageData instances
Issue 13021: RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert).
Issue 13022: mapping a number of methods
Issue 13024: Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01
Issue 13025: Removal of alerts is not clearly addressed in the spec
Issue 13026: UpdateAlert not useful, so remove it from the spec
Issue 13027: Consistently start methods with capitals (or not).
Issue 13028: Operation Unregister should be UnregisterReceiver
Issue 13029: Enable receiver hierarchy per alert template?
Issue 13030: Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType?
Issue 13031: Section 7.3 hierarchy
Issue 13032: Section 6.3.6: RegisterReceiver
Issue 13033: Section 6.2, 7.1: Name inconsistency
Issue 13034: ALMAS - IDL COM Corrections - Use SAFEARRAYs instead of the UDT array types ...TypeSet
Issue 13037: Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction
Issue 13042: ConfirmReceipt contains parameter ReceiverID

Issue 12287: Section 2.1 (almas-ftf)

This section seems to be misplaced. It is a table without headings or other explanations

- Conformance level 0 seems to me so weak that it may actually detract from the specification, i.e., the ability to conform at level 0 is so easy that it is not clear that any vendor would invest in Level 1 conformance.
- The statement in clause c) seems not to capture the intended conformance options. In our discussions, I think we agreed that we need an explicit list of optional conformance points and a statement of the ability to independently conform to each.

ALMAS Client Callbacks (comment on a previous version that has not been addressed) Package names or parts of the package names are reused and redundant within the class name. Examples include ALMAS::Client Callbacks::ALMASReceiver and ALMAS::Client Callbacks::ALMASNotificationListener

the descriptions of the model elements are not sufficient. For example, the description of ALMASNotificationListener is "Class provided by registering notification listeners for receipt of alert distribution notifications", which is not much more descriptive than the name of the class

It is real error that there is no relationship (including possibly a derivation) between AvailableAlertReceiver and ALMASReceiver. A link by a string name doesn't allow type-safe technology to check the proper provision of a ALMASReceiver as a available receiver.

The description of Alert has the text: "The message text is not fully filled in here." This looks like an editorial comment.

The text for the attribute CurrentState implies that there is a constraint between the allowed values and the category of the alert. These constraints need to be formally captured, e.g., through OCL.

This section provides an extension mechanism for AlertData so that this data can safely be transferred to products that don't understand the extensions. The requirements that receipt of any of this data not be "dropped" etc. need to be clarified. Also, there should be the possibility for providing a "type" indication (possibly either a string or enumeration) that would allow different products to interpret different extensions.

the format of this string needs to be specified so that different products can parse it consistently and thus can interoperate. 

Each of these operations, in fact, only work with an XML file that conforms to a particular XSD, which is defined later in the specification. This needs to be made explicit

 Current schema only allows one Alert Template per XML file. Correct to allow more than one alert.

Add an extra optional parameter in Dynamic_Message_Data_T "Max_Text_Length" for the Text variable data to aid sizing the final text when attempting to expand the dynamic text.

Sections 2.8.11 &  2.8.1.3 LPSTR types should be changed to BSTR (automation type).

 _put_ALMAS_SystemID - parameter changed to "in out" instead of "in" because of compiler limitation for parameter type BSTR.
 GetFilledMessageText - parameter MessageText changed to "in out" instead of "out" - compiler limitation for type BSTR.

Sections 2.6.1.2 &  2.8.1.2 - Inconsistent naming of the Call Status parameter. Some methods define it as CallStatus, others as Status. Suggest we change methods which define the parameter as Status to CallStatus.

Section 2.6.1.3,  2.3.3.5.1 & 2.7.4.2  Method RaiseAlertFromOverrides - optional parameters are not supported in C++ as defined in version 7 page 37 for this method. 'Optional' parameters can be supported if the parameters are changed to pointers. Parameters that are not required can then be passed in as NULL.

Added prefix "ALMAS_" to enums to avoid conflict with existing definitions within our system.

Sections 2.6.1.3, 2.7.4.2, 2.8.1.3 Query - Method UpdateDynamicMessage takes in OldValue - why?

2.8.1.3 _get_ALMAS_SystemID,GetAlert,GetAlerts, GetTemplate and GetTemplateIDs - cannot return data directly. Will need to be returned from additional callbacks on the appropirate interfaces, so out parameter now removed and replaced with an input parameter to pass in the receiver's handle.

ALMAS configuration files contain not valid xsd constructs. E.g. Alert_Definitions.xsd/24-01-2008: xs:restriction not terminated. ALMAS_Categorisation.xsd/23-01-2008: space chars invalid in some attributes. ALMAS_Hierarchy.xsd/24-01-2008: invalid characters (--) in element. Solution: Validate configuration files with appropriate xml editor.

Method GetAllTemplateIDs of ALMASManager not mapped. Solution: Map to: DDS read with query condition.

By means of RaiseAlertFromData an alert can be raised that is not present in the ALMAS template database. However, receivers (ReceiverKind, see Section 6.2) can only be associated with templates. How can receivers now be defined? Solution: Include parameter AlertReceiverSet: StringSet (as with RaiseAlertFromOverrides)?

Is the priority attribute value independent of the category meaning that an information alert can have a higher priority than a situation alert?

Attribute TimeoutAction: There seems to be no way to inform somebody about a timeout. Solution: Enable notification by ALMASReceiver.stateChangeNotification(int, Enumeration) and adding Timed_Out to the enumeration.

ALMASReceiver.stateChangeNotification(int, Enumeration): The values of the Enumeration are not specified. Solution: Same enumerations as for Alert.CurrentState.

Catgorisation rules must be defined offline by means of the "ALMAS categorisation rule file". Rules can be attached and detached to alerts by means of methods "AttachCategorisationRule" and "DetachCategorisationRule". An alert can only be attached after it exists, so after it is raised. However, the intention of categorisation is to do an action (e.g. raising an alert) according to a condition on occurence of an event. There seems to be a chicken-and-egg problem. Solution: Attach/detach AlertTemplate instead of Alert?

The number of DynamicMessageData instances is fixed for an Alert(Template). This means that for a specific Alert only a fixed maximum number of tags can be used. When you want to raise an alert like "Tracks present in an area", this number should be dynamic.

RegisterReceiver mapped on DDS creation of a new listener/data reader (of topic ALMAS_Alert). ALMAS must know which ReceiverKinds are active in the system at a certain moment. For example which roles are played that are interested in alerts. A (future) Role management system will not export such a relation because it will not import ALMAS particulars. Worse, it is not even able to do so because in OpenSplice it is not possible to determine which listeners are present for a certain topic. Even when that would be possible, there is no way to relate listeners to e.g. roles. Solution: For registration declare a new topic containing a RKType?

It would be better to map a number of methods, which are now directly mapped on DDS level constructs, on control topics because of two reasons: 1. Without control topics a producer can not be directly notified of a producer or system related error/problem. E.g. when a producer produces a new alert, he can not be notified that this was not succesfull because no active receivers are present. 2. Much more important: An alert contains ""static"" information but also state information (e.g. AlertId, Currentstate, Receivers etc.). Only ALMAS should be allowed to maintain this information, not a producer. Because a producer can now write a complete Alert, it may also write state information. This would violate data hiding principles and therefore ALMAS would be unnecessarely complex and obscure. Solution: The following methods should map on control topics: 1. UpdateDynamicMessageData 2. SetAlertInhibited 3. RemoveAlertsWithDynamicMessageData 4. RaiseAlertFromOverrides 5. RaiseAlertFromData 6. UpdateAlert

Figure 6.5, page 28: wrong picture (same as next one). Solution: Copy correct picture from document c4i/2008-02-01

Removal of alerts is not clearly addressed in the spec. Should be addressed explicitly. Solution: Alerts are removed as follows: . For all alert categories holds that they are removed when cancelled by the producer. . Information and Warning alerts: Removed when an acknowledge is required and the appropriate acknowledge is given or when a timeout is defined when the timeout is expired or when no timeout is defined a general (adaptable) timeout is assumed. . Action alert: Removed when HandleAlert is called by all addressees. . Situation alert: Will not be removed when HandleAlert is called by all addressees. Will only be removed if cancelled by producer.

UpdateAlert:By means of an UpdateAlert a producer can update an already raised alert with new AlertData as parameter. Two problems here: 1. The producer may change all attributes of the AlertData making this very complex to realise. However, most, if not all attributes, are not likely te be changed. 2. The alert may already be partly (by some addresses) handled making the realisation even more complex. Solution: UpdateAlert not useful, so remove it from the spec.

Consistently start methods with capitals (or not).

Operation Unregister should be UnregisterReceiver

Hierarchy, as can be specified according the Receiver Hierarchy Configuration file is alert (Template) independent. Is this not too restrictive? Solution: Enable receiver hierarchy per alert template?

Section 7.3: How can be indicated that a ReceiverKind.RKType has no ReceiverKind.RKParentType? RKParentType is a string (1 ..10) in which whitespaces are allowed. Solution: Specify that no ReceiverKind.RKParentType is indicated by only whitespaces in the string. Or change stringtype string (0 .. 10) for which string(0) indicates no ReceiverKind.RKParentType

Section 7.3: The hierarchy is defined in the Receiver Hierarchy Configuration File and is alert independent, so for all templates the same. Therefore RKParentType should be removed from ReceiverKind related to AlertTemplate in order to prevent a lot of redundant information. Solution: Remove RKParentType from ReceiverKind related to AlertTemplate.Instead, introduce a seperate class ReceiverHierarchy. Note that this has quite an impact on the PSMs! 

Section 6.3.6: RegisterReceiver: Parameter AvailableAlertReceiver.ReceiverKind.RKParentType can not be filled by the caller with useful information because it is not relevant here. Solution: Remove this parameter

Section 6.2, 7.1: Name inconsistency: AlternativeAction in section 6.2 is Alert_Responses in section 7.1. Solution: Use the same names.

We should be using the DCOM SAFEARRAY type instead of  the UDT array types ALMAS_ReceiverKindTypeSet, ALMAS_DynamicMessageDataTypeSet, ALMAS_StaticMessageTypeSet, ALMAS_AlertDataExtraAttributesTypeSet.
 

Struct ALMAS_AlertReportType: string AlternativeAction should be ALMAS_Stringset AlternativeAction

ConfirmReceipt contains parameter ReceiverID. This parameter seems to be not neccessary since ConfirmReceipt of one Responder is enough to enter the Received state. Solution: Remove parameter.