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 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 DDS-Xtypes specification now provides a standard way of specifying keys. This specification should use that mechanism

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

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 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 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 formatting of tables for operations for interface classes doesn't aid readability

The PSM sections of the specification include the code from the PSM machine readable files. This is duplication and a potential source of error, whilst not especially helpful to be provided outside of an IDE editor.

Sequences of dynamic data and static message have been defined to be nullable in method RaiseAlertFromOverrides. As the sequence can have zero length this is an unnecessary level of indirection in the DDS/IDL PSM.

The resolution to Issue ALMAS14-9 introduced an error into the operation table. The type name was given an "ALMAS_" prefix, which is a PSM namespace convention and should not appear in the PIM.

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
...