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

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.

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

In describing the PIM structure, four packages are described plus an optional one (ALMAS Categorization). However in the detail one of the packages (ALMAS Configuration) is actually a class within the ALMAS Management package.

The description of GetAlert would be improved by describing how the ID for an Alert is known

Section 6.5 on Dynamic Behaviour would aid the understanding of the other parts of section 6, but it's existence isn't well sign-posted within the section. The roles of the interfaces declared aren't very clear with the sequence diagrams in particular needed to show where all the parts fit in.

The description of ALMAS Manager does not give a clear picture of where it fits into the ALMAS system.

The specification does not standardise the logging mechanism. This could be achieved by PSM specific means.

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 summaries for operations AttachCategorisationRule and DetachCategorisationRule refer to Categorization Rules. Whilst there is some description in section 6.4 there is no overview of purpose prior to this point or forward sign-posting to section 6.4, so the purpose of these methods is left somewhat opaque.

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.

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

The extra attribute mechanism is a useful extension mechanism for providing additional information and/or functionality relating to an alert. However, in the current specification there isn't a way to do this using predefined alert templates with runtime parameters.

The Summary Description for RemoveAlertsWithDynamicMessageData refers to a real world object being removed. This is just one reason for using this method; others exist. In general this is a method to remove all alerts that refer to a specific value.

The features of the alert data model supporting multiple languages are not brought out well in the description. The description of static messages should discuss that there is intended to be one static message instance for each supported language variant

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.

The formatting of tables for operations for interface classes doesn't aid readability

It is unclear whether it is an error for an Alert Template to be RaiseToAll and to have receivers and/or secondary grouping specified.

The data model doesn't support multiple languages for the dynamic message data - but this is not made clear in the descriptive text.

Operation SetLanguage is described as setting the language for a specific receiver. However the data model has the text for all languages (potentially) delivered to all receivers. Therefore it is unclear what the SetLanguage operation is supposed to achieve.

GetFilledMessageText doesn't have a language parameter so it's implementation is unable to determine which static message from a set to use as a basis for performing message text dynamic parameter substitution.

The error condition on specifying an unsupported language for the alert is not described for the SetLanguage operation.

Receiver Kind Type should be unique
Parent should have it's own Receiver Kind definition
Parent of a Receiver Kind should not introduce a circularity

It is unclear whether it is an error condition to refer to a receiver before it has been registered or defined in a receiver hierarchy file. E.g. in an alert template configuration file, or when raising an alert (override or from data).
It is also unclear whether when registering a receiver it must match an entry in the hierarchy file.
It is also unclear whether it is permissible to call the LoadReceiverHierarchy multiple times and if so what semantics are expected.

It is unclear whether the following are error conditions:
Duplicate template id with previous load
Unsupported variable type in dynamic message data
Unsupported type of data in alert data extra attributes
Mismatched tags between dynamic and static messages
Missing text for mandatory languages
Capacity limits exceeded

The spec does not appear to offer an interface for an alert client to be informed of the alternative or non-standard choice that has been made in response to an alert.

The description of SetAlertInhibited says "... suppress or allow the raising of all alerts of that template"
This would suggest that calls to methods such as RaiseAlertFromTemplate for this template would subsequently fail (or succeed). An alternative interpretation is that these methods succeed but that Receivers ignore the corresponding Alert instance that is created.
For implementation interoperability it must be clear as to which of these designs to follow.

The spec assumes "... that request IDs are generated by the caller and that they are unique across all ALMAS callers."
This assumption imposes system implementation specific behaviour on users of the ALMAS specification and reduces portability across ALMAS systems.

Topic types ALMAS_RegisterReceiver and ALMAS_UnregisterReceiver are not required as this functionality is covered by the statndard (DCPS) DDS Subscription Model.

The DDS-Xtypes specification now provides a standard way of specifying keys. This specification should use that mechanism

Alert_Template
Alert_Category
....
ConfirmationRequried
TimeoutAction

The enumerations in the XSD and the body are inconsistent.
See Timeout Action and Acknowledgement Model in the XSD and table 7.2.2.1

Pleas fix this form so it doesn't wipe data on verification errors and keep unchecking the agree box

Timeout Action:
7.2.2.1

XSD CancelOnly, NotifyOnly, CancelWithNotify

AcknowledgementModel
7.2.2.1

XSD AckByNone, AckByAnyone, AckByAll

Also inconsistencies in the element naming in that some use underscores between words and others do not
Alert_Template
Alert_Category
Secondary_Grouping
...
TimeoutAction
ReliablyDistributed
MessageText
...