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.