The specification appears to imply functionality that should be applied in the case of safety critical systems - ConfirmationRequired attribute of AlertData. This is in appropriate - the spec should do no more than offer this as an example use case for potential mitigation.

Remove references to safety criticality

Remove references to safety critical system design. Use of ALMAS should in no way be suggestive of contributing to a safety case.

The description of TimeoutAction attribute of Class AlertData describes its enumeration type rather than the attribute itself

Describe the timeout action attribute not the type

Replace text with a description of the meaning of the attribute with respect to the alert.

It is not clear whether there are semantic differences between the events that trigger the ALMAS Client Callbacks ALMASNotificationListener and ALMASReceiver. The method summaries suggest that ALMASNotificationListener relates to safety critical alerts, but elsewhere in the spec this is only an example usage.

AlertDistributionNotification corresponds to Raised state

The AlertDistributionNotification should be triggered when the alert is in the Raised state (the first state for state machines in subsections 6.5.1 & 6.5.2).
Clarify that StateChangeNotifications are also generated for new alerts.

The Acronyms and Abbreviations section is missing entries - e.g. for PSM technologies such as DDS.

Add entries for acronyms from PSM

Add:

• COM
• DCPS
• DDS
• DLRL
• GraphQL
• QoS

For attribute TypeOfByteData in Class AlertDataExtraAttributes
Unclear whether or not strings should be null terminated.
Unclear whether only one or multiple int, float values etc. are valid for one instance of the class
Unclear whether the size of the value attribute not matching or being a multiple of the type from the TypeOfByteData attribute is an error condition

Clarify validity of byte data in AlertDataExtraAttributes

Strings are an array of UTF-8 characters without null termination
Multiple values of a particular data type are valid
The size of the value must be a multiple of the type of data unit size for Integer 16, 32 or 64
There should be a specific type (7) for media types. The description string should be the type / substype tree for media types.

The summary for RemoveAlertsWithDynamicMessageData concludes with stating that implementation is optional. This is true for all methods in this interface - but is stated for only this one.
Also there is a rogue full-stop (period) in the text.
The ALMAS responder extensions do not have equivalent text either.

Remove implementation optional text

Remove the text that inconsistently appears for RemoveAlertsWithDynamicMessageData

The semantics of the reason attribute of the CallStatus call should be encapsulated as an enumeration. Also the formatting of the description of the attribute doesn't help clarity.

Defer interface changes to v1.4

For scheduling reasons defer changes impacting IDL etc. to the next RTF

The semantics of the reason attribute of the CallStatus call should be encapsulated as an enumeration. Also the formatting of the description of the attribute doesn't help clarity.

The Conformance section talks about general conformance level 1 functionality, but then adds extensions which are also numbered 1 to 4. There could be confusion as to what conformance to level 1 actually means.
Also a useful system could be composed of components that implement a subset of the core (level 1) interface. Therefore, there should be one or more additional levels of conformance defined that reflects this.

Basic, Advanced and Extended Conformance on an Interface Role Basis

There are three distinct roles in the ALMAS abstracted by the interface classes defined in the ALMAS Management package: Producer, Manager and Receiver. Conformance should recognise that a conforming application will be performing only one of these roles and therefore only a subset of the interface will be applicable.
Additionally, conformance should recognise a minimal basic level of conformance as a pathway to adoption and use of the specification. This is the set of methods to support raising and receiving alerts without templates, customisation or modification.

Attribute DataValue for DynamicAlertData has instantia-tion. This does not need to be split.

Remove hyphen

remove hyphen in description

The description of class DynamicMessageData and its DataTag attribute is ambiguous as to whether one or two percent (%) markers are required. Also the protocol is ambiguous when there are 10 or more markers. Also, particularly with a single % marker there isn't a defined way to escape the markers.

Clarify Dynamic Message Substitution

Placeholder tags to be designated by a single exclosing percent characters.
Multiple - in principle unbounded - replacements supported with each tag enclosed by space (or other non-alphanumeric character). The examples given in the current specification (t1, tn) are examples and more meaningful tags can be used and are encouraged (e.g. %number%, %score% or %name%).
It is not necessary to provide a means of specifying a way to express %name% as a literal substring in a static message as this would have no meaning to a system user.
Additionally, it should be possible to specify a replacement at the start or end of the static message. Equally it should be possible to have dynamic data at the start or end of the message and it should be possible to use punctuation around it (e.g. a comma). Therefore substitution points should be defined by:
(start | non-alphanumeric)%t(numeric){end | non-alphanumeric)
It is an error to specify static and dynamic data message instances with different substitution tags for the same alert template. In particular all static message instances (for different language locales) must have the same substitution set.

The description of the status attribute for class AlertData repeats the information for the Status enumeration. This is also poorly formatted and so difficult to read.

Remove duplicate information

Remove duplication of enumeration values for status attribute

The Normative References is missing entries for the PIM and PSM technologies

Add new Normative Reference Section

Base style on TDAI normative reference section
Add references for DDS, IDL, GraphQL, COM, CORBA, XML