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

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.

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.

Signpost behavior subsection from the start of section 6

Add an overview from the beginning of section 6 that introduces the PIM.

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

Generalise description of RemoveAlertsWithDynamicMessageData

Make the removal of a real-world object an example of a more general principle.

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.

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

Clarify multi-language support in StaticMessage class

State that there should be one static message for each language supported

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.

Describe as three main packages

Describe as three packages as presented in subsection 6.1, 6.2 & 6.3

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

GetAlert gets current data for a known alert

The operation retrieves the current data for an alert already known to the client component. E.g. because that component raised the alert and stored the AlertID passed out, or the component received a notification about 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

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

State error condition for load template set

The following are error conditions

• duplicate of existing template id
• unsupported data type for dynamic message data
• type of byte data out of range in extra attributes
• mismatched tags between dynamic and static messages
• missing text for mandatory languages
• capacity limits exceeded
  Where applicable they should be stated for raising alerts as well.

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

Fail attempts to raise alerts from inhibited templates

Implementations of the ALMAS Producer interface should fail attempts to raise an alert for a template for which SetAlertInhibited has been called (with Inhibited set to True). This effects RaiseAlertFromOverrides, RaiseAlertWithDynamicData & RaiseAlertFromTemplate.

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.

Request Uniqueness to be through Producer ID and Request ID

ALMAS Producers (Clients) already specify a combination of request_id and producer_id in their method calls to ALMAS Manager. Therefore as producer_Id is unique to a producer request_id should only need to be unique to a single producer (client). This is advantageous as it does not require management to (for instance) pre-allocate request id ranges to different clients.
A second consideration is that to apply the DDS Security model topic instance should be unique to a client so that each client is only permissioned for the data that relates to it. Therefore topic names should be post-fixed with the producer ID.

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.

Resolve alert before delivery

Alerts should be resolved by the ALMAS Manager prior to delivery to each ALMAS Responder. In particular delivered Alert instances should contain a single static message instance and no dynamic data.

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.

ALMAS Manager has knowledge of language selection

The ALMAS Manager has knowledge of any language selection for each receiver because of its SetLanguage operation.
Accordingly MessageText is resolved for each receiver and the filled (resolved) message text can be calculated and returned.

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

RaiseToAll error condition

State that when RaiseToAll is set it is an error to have Receiver Kind instances or a secondary grouping defined.

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 error condition on specifying an unsupported language for the alert is not described for the SetLanguage operation.

Include unsupported language error condition

Include error condition for completeness and portability. Map Reason to:
4 = Requested Service Unavailable

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.

Clarify Receiver Semantics

It is an error to refer to a receiver before it has been defined by load receiver hierarchy. (But receivers don't have to be registered - for instance a user with the relevant role may not have logged on to the system).
When registering a receiver it is an error for the receiver to not correspond to a hierarchy file entry.
Load receiver hierarchy may be invoked more than once per execution lifetime of ALMAS Manager, for instance by multiple producers to load a specific hierarchies for their needs. The semantics in this case are additive whilst disjoint: producers should define receivers in their own namespace; it is an error to define the same receiver in multiple hierarchies. Receiver instances may register themselves multiple times with receiver names from different producer namespaces.
Alternatively ALMAS Configuration maybe performed by a system function (entirely or in part). If entirely, the configuration operations are called once by the system function, producers don't invoke the configuration interface and receivers only register themselves once for the system defined receiver name.

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

Place additional restrictions on Receiver Hierarchy configuration schema

Receiver Kind Type uniqueness should be enforced using an xs:unique element within Receiver_Hierarchy_T acting on //Receiver_Kind/Type and scoped to itself (i.e. the hierarchy content).
Parents should be declared as Receiver_Kind elements containing the elements of which they are parents (their 'children'). This avoids circular dependencies as each name is then only used once and the relationships are structural.
'Parent-Child' isn't a great abstraction for this use case. Having inverted the relationships, 'priority receiver' would be better terminology. Therefore have each Receiver_Kind contain a Priority_Receivers element each with zero-or-more Receiver_Kind elements. Update the description for the file accordingly at the start of section section 7.3
Parent should have it's own Receiver Kind definition
Parent of a Receiver Kind should not introduce a circularity

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

Clarify concurrent multi-language support

Concurrent support for multiple languages can be achieved by using multiple instances of static message and dynamic message data; one per language and one per language-placeholder combination resepectively.

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.

Defer clarification on optional PIM

ALMAS Categorization is an optional PIM, therefore resolution is lower priority so for scheduling reasons resolution is postponed to a future RTF.

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

Address issues requiring IDL changes in v1.4

For purposes of scheduling, a strategy of completing semantic clarifications and other minor typographic issues in v1.3 and moving to address issues requiring more substantive changes is proposed.

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.

Address issues requiring IDL changes in v1.4

For purposes of scheduling, a strategy of completing semantic clarifications and other minor typographic issues in v1.3 and moving to address issues requiring more substantive changes is proposed.

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

Defer extensive document changes to v1.4

The role of ALMAS Manager with respect to the other ALMAS components should be clarified with reference to a set of behavioural diagram that describe how the various operations defined fit together.
For scheduling reasons this is best done for v1.4.

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

Address issues requiring IDL changes in v1.4

For purposes of scheduling, a strategy of completing semantic clarifications and other minor typographic issues in v1.3 and moving to address issues requiring more substantive changes is proposed.

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

Defer extensive document changes to v1.4

ALMAS logging could be standardised by reference to a set of standard mechanisms in the PSM section, which refer to PSM specific method such as DDS serialisation standards.
This change would also be better made after removal of the obsolete DLRL PSM.

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

Defer large editorial change to a future RTF

The layout and syntax of the tables in the specification that describe the operations could indeed be much improved. However, such a resolution would have a very large editorial impact and with regard to scheduling it is proposed to defer this to a later 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.

Defer interface changes to v1.4

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

The declaration of the DynamicMessages field is incomplete and incorrect.
It is missing the DynamicMessages field name
It has an extra space in the type's package qualification
The type should be ALMAS_DynamicMessageDataTypeSet

Fix Issues with DynamicMessages field

Apply suggested changes from the issue

No space between sentences. Would be improved by inserting new-lines.

Also RaiseAlertWithDynamicData has an extra new-line.

Also RaiseAlertFromData needs a new-line instead of a space.

Improve Raise Alert Summary Formatting

Add improvements as suggested by the issue.

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.

In the PIM the parameter for DynamicMessageDataSet in operations RaiseAlertFromOverrides and RaiseAlertWithDynamicData is StringSet, but in the CORBA and DDS PSM the type is DynamicMessageDataTypeSet (which is a sequence of the DynamicMessageDataType struct)

Re-align PIM for DynamicMessageDataSet

Change the PIM type to match the PSMs as the additional information in the PSM types is required to enable the required behaviour. Also align the parameter names (i.e. change to DynamicMessages).

There is no rationale for the DDS DCPS/IDL PSM topic type ALMAS_CreatedAlert.
By closer inspection, this is introduced to map to the AlertID out parameter of the various alert creation methods in the Producer interface.
It is needed so that producer know the alert id and are therefore able to cancel alerts that they have previously raised.

Add explanation of ALMAS_CreatedAlert

Add explanatory text to the ALMAS Management DDS DCPS/IDL PSM section

There is an erroneous space in the summary cell of RemoveAlertsWithDynamicMessageData
"specific rea l world object" should be "specific real world object"

Remove space in real

Remove space (this is only in the published spec not in the 1.1 RTF convenience doc)

In the CORBA PSM there are two operations with the name RaiseAlertFromOverrides but RaiseAlertWithDynamicData is missing.

Change second RaiseAlertFromOverrides to RaiseAlertWithDynamicData

In the CORBA PSM change the second occurrence of RaiseAlertFromOverrides to RaiseAlertWithDynamicData so as to match the PIM

The use of "pecking order" rather than prioritisation is unhelpful, particular if readers don't have English as first language.

Rework Pecking Order

Change pecking order to actionee prioritisation

"none standard" should be "non-standard"

Fix typo in AlternativeAction documentation element

none should be non

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

Remove hyphen

remove hyphen in description

Section heading is
OMG ORBA/IDL Platform Specific Model
should be
OMG CORBA/IDL Platform Specific Model

Add C for CORBA back

Correct Typo

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

Section 11 Changes or extensions required to adopted OMG
specifications applies to the submission and should not have been retained in the published specification

Remove section 11

Remove Section 11: Change or extensions required to adopted OMG specifications

This is missing an apostrophe and is in any case could be stated more clearly

Improve UpdateAlertPriority Summary description

Improve description to be "Updated the priority of existing alert instances that have previously been raised."

Refer to system components rather than system objects in first sentence

Change objects to components

Change objects to components in ALMAS Producer description

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

Extra hyphen in summary for UnregisterReceiver (avail-able)

Remove hyphen in UnregisterReceiver

remove hyphen in available

Add a GraphQL PSM option using the mapping defined in the TDAI specification for implementations using web technologies

Add GraphQL Platform Specific Model

Add a GraphQL platform specific model as an alternative technology particular aimed at contexts using this technology and other similar web technologies.
Base the PSM mappings on those defined for the TDAI specification, noting the principles of categorizing the PIM noted in the DDS / IDL / DCPS PSM.
The schema is to be added to the normative machine readable files.