XTCE12 — Derived Issue: Update base alarm definition types

This new issue is derived from existing issues because it is not possible to attach more than 1 resolution to an issue.

Update alarm type base definition types

This is the first resolution for the alarm definition issues. The overall resolution is broken up into several smaller resolutions for ease of review. A number of alarm changes have already been applied in other resolutions.

The first change is to update the complexType named "BaseAlarmType" immediately after the "AlarmType" definition. This will be used in the next update. This change applies annotation updates and sets the @name to be optional.

<complexType name="BaseAlarmType" abstract="true">
<annotation>
<documentation xml:lang="en">Supplies an optional non-reference-able name and short description for alarms. Also includes an optional ancillary data for any special local flags, note that these may not necessarily transfer to another recipient of an instance document.</documentation>
</annotation>
<sequence>
<element name="AncillaryDataSet" type="xtce:AncillaryDataSetType" minOccurs="0"/>
</sequence>
<attribute name="name" type="string" use="optional">
<annotation>
<documentation xml:lang="en">The alarm definition may be named.</documentation>
</annotation>
</attribute>
<attribute name="shortDescription" type="xtce:ShortDescriptionType">
<annotation>
<documentation xml:lang="en">An optional brief description of this alarm definition.</documentation>
</annotation>
</attribute>
</complexType>

The updated BaseAlarmType defined above is used in the modification below for the "CustomAlarmType" complexType. It is also used later. Add this new type definition after the already defined "ContextMatchType". This segregates what was previously an element definition.

<complexType name="CustomAlarmType">
<annotation>
<documentation xml:lang="en">Describe a custom, algorithmic alarm condition. The algorithm is assumed to return a boolean value: true or false. See AlarmType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseAlarmType">
<sequence>
<element name="InputAlgorithm" type="xtce:InputAlgorithmType">
<annotation>
<documentation xml:lang="en">Algorithm returns a boolean.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>

With these two modifications, the new definition complexType for the "AlarmType" can be applied. Replace the existing definition of the AlarmType with the following definition.

<complexType name="AlarmType" abstract="true">
<annotation>
<documentation xml:lang="en">Defines a base schema type used to build up the other data type specific alarm types. The definition includes a count to go into alarm (minViolations – the counts to go out of alarm is the same), a condition style alarm and a custom alarm. See AlarmConditionType, CustomAlgorithmType, BinaryAlarmConditionType, BooleanAlarmType, BinaryContextAlarmType, EnumerationAlarmType, NumericAlarmType, StringAlarmType, TimeAlarmType, TimeAlarmConditionType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseAlarmType">
<sequence>
<choice minOccurs="0">
<element name="AlarmConditions" type="xtce:AlarmConditionsType">
<annotation>
<documentation xml:lang="en">A MatchCriteria may be specified for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation>
</annotation>
</element>
<element name="CustomAlarm" type="xtce:CustomAlarmType">
<annotation>
<documentation xml:lang="en">An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter.</documentation>
</annotation>
</element>
</choice>
</sequence>
<attribute name="minViolations" type="xtce:PositiveLongType" default="1">
<annotation>
<documentation xml:lang="en">The number of successive instances that meet the alarm conditions for the alarm to trigger. The default is 1.</documentation>
</annotation>
</attribute>
<attribute name="minConformance" type="xtce:PositiveLongType">
<annotation>
<documentation xml:lang="en">Optionally specify the number of successive instances that do not meet the alarm conditions to leave the alarm state. If this attribute is not specified, it is treated as being equal to minViolations (symmetric).</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

Lastly for this resolution, update some documentation elements. For the existing "ConcernLevelsType" simpleType, replace the documentation annotation with the following:

<documentation xml:lang="en">Defines six levels: Normal, Watch, Warning, Distress, Critical and Severe. Typical implementations color the "normal" level as green, "warning" level as yellow, and "critical" level as red. These level definitions are used throughout the alarm definitions. Some systems provide a greater fidelity with the additional levels provided here. The "normal" level is not typically needed because "normal" should be construed as none of the concern levels evaluating to true. For cases where definiing "normal" is needed, refer to the specific alarm definition types.</documentation>