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.

Remove erroneous prefix

Remove "ALMAS_" so that type is just "AlertDataExtraAttributesTypeSet"

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.

Remove code from PSM sections

Remove the code listings from sections 7, 8, 9 10 & 11

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.

Remove optionality from sequences

In the DDS PSM remove optionality from the sequence parameters in the RaiseAlertFromOverrides method.

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.

Add Extra Attributes to Alert Methods based on Templates

Add ExtraAttributes parameter of type ALMAS_AlertDataExtraAttributesTypeSet to methods RaiseAlertFromOverrides and RaiseAlertWithDynamicData.

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.

Improve the formatting of the attribute description

As there is significant PSM as system specific potential for additional reasons codes 5 and over, changing to an enumeration is not necessarily beneficial. In particular it does not outweigh the negative consideration of making a breaking change,
However, the formatting of the attribute description should certainly be corrected. Each code should be on a new line.
Also keep table on a single page and remove blank row.

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

Insert Extra Whitespace

The tables are difficult to read particularly because long parameter lists are on the same logical line. The document has consequently adjusted the width of columns 1 & 2 to be large, leading to a very narrow column for the summaries in some tables.

For Operation Tables in sections 6.1 & 6.3
Newline characters should be inserted:

• between the operation name and the opening parenthesis in column 1
• before the opening square bracket around parameters in column 2
• after the closing square bracket around parameters in column 2
• after each comma separating parameters in column 2
  Additional spaces are after commas between parameters should be removed from column 2
  Column widths should be adjusted to maximise the width of column 3 (summary) subject to not breaking individual words/identifiers across a line in columns 1 & 2

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

Add logging requirements to the PSM sections

In the description of ALMASLogger explicitly refer to the PSM sections for implementation guidance.

XML PSM is specific to configuration

CORBA, COM & GraphQL PSMs to use Open Telemetry

DDS PSM may use Open Telemetry, otherwise the DDS Data Space may be recorded with a DDS Logging tool

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

Add clarification to the ALMASManager introduction

In the Introduction to the ALMASManager interface section note that a coordinating component should implement the ALMASManager, ALMASProducer and ALMASResponder interfaces.

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.

Signpost the meaning of the ALMAS Categorization PIM

Make clear in both the overall PIM introduction and the Management interface extension for attaching and detaching rules that the Categorization PIM is about defining a model for attaching event-based categorization rules to alerts.

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.

Add Alternative Action to method Handle Alert

The HandleAlert method should have an AlternativeAction parameter so that any alternate action taken by the receiver can be indicated to the originating alert client. As alternative actions are strings, an empty string has the meaning of no alternate action selected.

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

Add @key Annotation

In the DDS/IDL PSM use the @key Annotation as defined in IDL 4.2 (for XTYPES) - see https://www.omg.org/spec/IDL/4.2/PDF 8.3.2.1. for all the key values.
Note that the keys are currently defined in the keylist defined by pragma.
For backwards compatibility use a processor directive variable to switch between the styles of definition.

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

Remove register and unregister receiver from DDS PSM

These methods are unnecessary as they are equivalent to the built-in subscriber-listener interface in DDS / DCPS.
Remove from the IDL for the PSM and add an explanation to the PSM mapping section.