Issues for Mailing list of the Alerts Management Service 1.0 (ALMAS) Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 12287: Section 2.1
Issue 12288: 2.2 Conformance requirements
Issue 12289: 2.3.1 ALMAS Client Callbacks
Issue 12290: 2.3 General
Issue 12291: Section 2.3.1 & 2 Section 2.3.2.1
Issue 12292: Section 2.3.2.1
Issue 12293: 2.3.2.1
Issue 12294: 2.3.2.3 AlertDataExtraAttributes
Issue 12295: 2.3.2.8 DataTag
Issue 12296: 2.3.3.1.1 ReceiverKind Operations

Issue 12287: Section 2.1 (almas-ftf)

This section seems to be misplaced. It is a table without headings or other explanations

- Conformance level 0 seems to me so weak that it may actually detract from the specification, i.e., the ability to conform at level 0 is so easy that it is not clear that any vendor would invest in Level 1 conformance.
- The statement in clause c) seems not to capture the intended conformance options. In our discussions, I think we agreed that we need an explicit list of optional conformance points and a statement of the ability to independently conform to each.

ALMAS Client Callbacks (comment on a previous version that has not been addressed) Package names or parts of the package names are reused and redundant within the class name. Examples include ALMAS::Client Callbacks::ALMASReceiver and ALMAS::Client Callbacks::ALMASNotificationListener

the descriptions of the model elements are not sufficient. For example, the description of ALMASNotificationListener is "Class provided by registering notification listeners for receipt of alert distribution notifications", which is not much more descriptive than the name of the class

It is real error that there is no relationship (including possibly a derivation) between AvailableAlertReceiver and ALMASReceiver. A link by a string name doesn't allow type-safe technology to check the proper provision of a ALMASReceiver as a available receiver.

The description of Alert has the text: "The message text is not fully filled in here." This looks like an editorial comment.

The text for the attribute CurrentState implies that there is a constraint between the allowed values and the category of the alert. These constraints need to be formally captured, e.g., through OCL.

This section provides an extension mechanism for AlertData so that this data can safely be transferred to products that don't understand the extensions. The requirements that receipt of any of this data not be "dropped" etc. need to be clarified. Also, there should be the possibility for providing a "type" indication (possibly either a string or enumeration) that would allow different products to interpret different extensions.

the format of this string needs to be specified so that different products can parse it consistently and thus can interoperate. 

Each of these operations, in fact, only work with an XML file that conforms to a particular XSD, which is defined later in the specification. This needs to be made explicit