Propose to correct the Argument Type structures for proper argumentRef and parameterRef support
This is something of a major issue and it took significant effort from the team to get all of this lined up. This resolution is quite large, but easy to apply.
I considered splitting it up further, but taking pieces out individually would make for an invalid schema definition.
The first change occurs in the replacement of the BaseDataType in order to add more descriptive annotations.
Before:
<complexType name="BaseDataType" abstract="true">
<annotation>
<documentation xml:lang="en">An abstract type used by within the schema to derive other data types by the ground system. </documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="UnitSet" type="xtce:UnitSetType" minOccurs="0"/>
<choice minOccurs="0">
<element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType"/>
<element name="FloatDataEncoding" type="xtce:FloatDataEncodingType"/>
<element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType"/>
<element name="StringDataEncoding" type="xtce:StringDataEncodingType"/>
</choice>
</sequence>
<attribute name="baseType" type="xtce:NameReferenceType">
<annotation>
<documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition. </documentation>
<appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations. </appinfo>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BaseDataType" abstract="true">
<annotation>
<documentation xml:lang="en">An abstract schema type used by within the schema to derive the other simple/primitive engineering form data types: BooleanDataType, BinaryDataType, StringDataType, EnumeratedDataType, FloatDataType and IntegerDataType. The encoding elements are optional because they describe the raw wire encoded form of the data type. Encoding is only necessary when the type is telemetered in some form. Local variables and derived typically do not require encoding.</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="UnitSet" type="xtce:UnitSetType" minOccurs="0">
<annotation>
<documentation xml:lang="en">When appropriate, describe the units of measure that are represented by this parameter value.</documentation>
</annotation>
</element>
<choice minOccurs="0">
<element name="BinaryDataEncoding" type="xtce:BinaryDataEncodingType">
<annotation>
<documentation xml:lang="en">Binary encoding is typically a "pass through" raw encoding form where one of the more common encodings is not required for the parameter. A custom transformation capability is available if needed.</documentation>
</annotation>
</element>
<element name="FloatDataEncoding" type="xtce:FloatDataEncodingType">
<annotation>
<documentation xml:lang="en">Float encoding is a common encoding where the raw binary is in a form that gets interpreted as a decimal numeric value.</documentation>
</annotation>
</element>
<element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType">
<annotation>
<documentation xml:lang="en">Integer encoding is a common encoding where the raw binary is in a form that gets interpreted as an integral value, either signed or unsigned.</documentation>
</annotation>
</element>
<element name="StringDataEncoding" type="xtce:StringDataEncodingType">
<annotation>
<documentation xml:lang="en">String encoding is a common encoding where the raw binary is in a form that gets interpreted as a character sequence.</documentation>
</annotation>
</element>
</choice>
</sequence>
<attribute name="baseType" type="xtce:NameReferenceType">
<annotation>
<appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations.</appinfo>
<documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
For better Argument support in the CommandMetaData, there needs to be a new ArgumentBaseDataType.
Before (does not exist) - add after BaseDataType:
<complexType name="ArgumentBaseDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to BaseDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="UnitSet" type="xtce:UnitSetType" minOccurs="0">
<annotation>
<documentation xml:lang="en">When appropriate, describe the units of measure that are represented by this argument value.</documentation>
</annotation>
</element>
<choice minOccurs="0">
<element name="BinaryDataEncoding" type="xtce:ArgumentBinaryDataEncodingType">
<annotation>
<documentation xml:lang="en">Binary encoding is typically a "pass through" raw encoding form where one of the more common encodings is not required for the argument. A custom transformation capability is available if needed.</documentation>
</annotation>
</element>
<element name="FloatDataEncoding" type="xtce:FloatDataEncodingType">
<annotation>
<documentation xml:lang="en">Float encoding is a common encoding where the raw binary is in a form that gets interpreted as a decimal numeric value.</documentation>
</annotation>
</element>
<element name="IntegerDataEncoding" type="xtce:IntegerDataEncodingType">
<annotation>
<documentation xml:lang="en">Integer encoding is a common encoding where the raw binary is in a form that gets interpreted as an integral value, either signed or unsigned.</documentation>
</annotation>
</element>
<element name="StringDataEncoding" type="xtce:ArgumentStringDataEncodingType">
<annotation>
<documentation xml:lang="en">String encoding is a common encoding where the raw binary is in a form that gets interpreted as a character sequence.</documentation>
</annotation>
</element>
</choice>
</sequence>
<attribute name="baseType" type="xtce:NameReferenceType">
<annotation>
<appinfo>Must be derived from a like type (e.g,, String from String). No circular derivations.</appinfo>
<documentation xml:lang="en">Used to derive one Data Type from another - will inherit all the attributes from the baseType any of which may be redefined in this type definition.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Next, update the BinaryDataEncodingType to add improved annotations.
Before:
<complexType name="BinaryDataEncodingType">
<annotation>
<documentation xml:lang="en">For binary data or for integer, float, string, or time data that is not in any of the known encoding formats. For any data that is not encoded in any of the known integer, float, string, or time data formats use a To/From transform algorithm.</documentation>
</annotation>
<complexContent>
<extension base="xtce:DataEncodingType">
<sequence>
<element name="SizeInBits" type="xtce:IntegerValueType"/>
<element name="FromBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Used to convert binary data to an application data type</documentation>
</annotation>
</element>
<element name="ToBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Used to convert binary data from an application data type to binary data</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BinaryDataEncodingType">
<annotation>
<documentation xml:lang="en">Describe binary data that is unmolested in the decoding/encoding or cannot be represented in any of the other data encoding formats. Optionally use the FromBinaryTransformAlgorithm and ToBinaryTransformAlgorithm element to describe the transformation process. See InputAlgorithmType for the transformation structure.</documentation>
</annotation>
<complexContent>
<extension base="xtce:DataEncodingType">
<sequence>
<element name="SizeInBits" type="xtce:IntegerValueType">
<annotation>
<documentation xml:lang="en">Number of bits this value occupies on the stream being encoded/decoded.</documentation>
</annotation>
</element>
<element name="FromBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Used to convert binary data to an application data type</documentation>
</annotation>
</element>
<element name="ToBinaryTransformAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Used to convert binary data from an application data type to binary data</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
For improved Argument support, a new ArgumentBinaryDataEncodingType is needed.
Before (does not exist) - add before BinaryDataEncodingType:
<complexType name="ArgumentBinaryDataEncodingType">
<annotation>
<documentation xml:lang="en">Identical to BinaryDataEncodingType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:DataEncodingType">
<sequence>
<element name="SizeInBits" type="xtce:ArgumentIntegerValueType">
<annotation>
<documentation xml:lang="en">Number of bits this value occupies on the stream being encoded/decoded.</documentation>
</annotation>
</element>
<element name="FromBinaryTransformAlgorithm" type="xtce:ArgumentInputAlgorithmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Used to convert binary data to an application data type</documentation>
</annotation>
</element>
<element name="ToBinaryTransformAlgorithm" type="xtce:ArgumentInputAlgorithmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Used to convert binary data from an application data type to binary data</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
A previous mistake was made in the definition of FloatSizeInBitsType where the size in bits could be 0, which makes no sense.
Before:
<simpleType name="FloatSizeInBitsType">
<restriction base="xtce:NonNegativeLongType">
<enumeration value="32"/>
<enumeration value="64"/>
<enumeration value="128"/>
</restriction>
</simpleType>
After:
<simpleType name="FloatSizeInBitsType">
<restriction base="xtce:PositiveLongType">
<enumeration value="32"/>
<enumeration value="64"/>
<enumeration value="128"/>
</restriction>
</simpleType>
Adjust the backwards compatible SizeInBits for StringDataEncoding elements and make the choice a sequence with optional on the termination and leading size:
Before:
<complexType name="SizeInBitsType">
<choice>
<element name="Fixed">
<complexType>
<sequence>
<element name="FixedValue" type="long"/>
</sequence>
</complexType>
</element>
<element name="TerminationChar" type="hexBinary" default="00">
<annotation>
<documentation xml:lang="en">Like C strings, they are terminated with a special string, usually a null character.</documentation>
</annotation>
</element>
<element name="LeadingSize" type="xtce:LeadingSizeType"/>
</choice>
</complexType>
After:
<complexType name="SizeInBitsType">
<sequence>
<element name="Fixed">
<annotation>
<documentation xml:lang="en">This is the simplest case of a string data type where the encoding size of the string does not change.</documentation>
</annotation>
<complexType>
<sequence>
<element name="FixedValue" type="xtce:PositiveLongType">
<annotation>
<documentation xml:lang="en">Size in bits of this string data type for both the memory allocation in the implementing software and also the size in bits for this parameter when it appears in a container.</documentation>
</annotation>
</element>
</sequence>
</complexType>
</element>
<element name="TerminationChar" type="hexBinary" default="00" minOccurs="0">
<annotation>
<documentation xml:lang="en">The termination character that represents the end of the string contents. For C and most strings, this is null (00), which is the default.</documentation>
</annotation>
</element>
<element name="LeadingSize" type="xtce:LeadingSizeType" minOccurs="0">
<annotation>
<documentation xml:lang="en">In some string implementations, the size of the string contents (not the memory allocation size) is determined by a leading numeric value. This is sometimes referred to as Pascal strings. If a LeadingSize is specified, then the TerminationChar element does not have a functional meaning.</documentation>
</annotation>
</element>
</sequence>
</complexType>
Update the StringDataEncodingType to improve and clarify the annotation, taking backwards compatibility into account:
Before:
<complexType name="StringDataEncodingType">
<annotation>
<documentation xml:lang="en">Describe common encodings of string data: UTF-8 and UTF-16. See StringDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:DataEncodingType">
<choice>
<element name="SizeInBits" type="xtce:SizeInBitsType">
<annotation>
<documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
</annotation>
</element>
<element name="Variable" type="xtce:VariableStringType">
<annotation>
<documentation xml:lang="en">A variable length string may change lengths between samples.</documentation>
</annotation>
</element>
</choice>
<attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="StringDataEncodingType">
<annotation>
<documentation xml:lang="en">Describe common encodings of string data: UTF-8 and UTF-16. See StringDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:DataEncodingType">
<choice>
<element name="SizeInBits" type="xtce:SizeInBitsType">
<annotation>
<documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
</annotation>
</element>
<element name="Variable" type="xtce:VariableStringType">
<annotation>
<documentation xml:lang="en">Variable length strings are those where the space occupied in a container can vary. If the string has variable content but occupies the same amount of space when encoded should use the SizeInBits element. Specification of a variable length string needs to consider that the implementation needs to allocate space to store the string. Specify the maximum possible length of the string data type for memory purposes and also specify the bit size of the string to use in containers with the dynamic elements.</documentation>
</annotation>
</element>
</choice>
<attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8">
<annotation>
<documentation xml:lang="en">The character set encoding of this string data type.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
For improved Argument support, add new ArgumentStringDataEncodingType before StringDataEncodingType.
New:
<complexType name="ArgumentStringDataEncodingType">
<annotation>
<documentation xml:lang="en">Identical to StringDataEncodingType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:DataEncodingType">
<choice>
<element name="SizeInBits" type="xtce:SizeInBitsType">
<annotation>
<documentation xml:lang="en">Static length strings do not change in overall length between samples. They may terminate before the end of their buffer using a terminating character, or by various lookups, or calculations. But they have a maximum fixed size, and the data itself is always within that maximum size.</documentation>
</annotation>
</element>
<element name="Variable" type="xtce:ArgumentVariableStringType">
<annotation>
<documentation xml:lang="en">Variable length strings are those where the space occupied in a container can vary. If the string has variable content but occupies the same amount of space when encoded should use the SizeInBits element. Specification of a variable length string needs to consider that the implementation needs to allocate space to store the string. Specify the maximum possible length of the string data type for memory purposes and also specify the bit size of the string to use in containers with the dynamic elements.</documentation>
</annotation>
</element>
</choice>
<attribute name="encoding" type="xtce:StringEncodingType" default="UTF-8">
<annotation>
<documentation xml:lang="en">The character set encoding of this string data type.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Update VariableStringType to add annotations and fix the choice to sequence with optional termination and leading size. Also a maxSizeInBits attribute is needed with the clarification for users.
Before:
<complexType name="VariableStringType">
<annotation>
<documentation xml:lang="en">Describe a variable string whose length may change between samples.</documentation>
</annotation>
<choice>
<element name="LeadingSize" type="xtce:LeadingSizeType"/>
<element name="DynamicValue" type="xtce:DynamicValueType"/>
<element name="TerminationChar" type="hexBinary"/>
<element name="DiscreteLookupList" type="xtce:DiscreteLookupListType"/>
</choice>
</complexType>
After:
<complexType name="VariableStringType">
<annotation>
<documentation xml:lang="en">Describe a variable string whose length may change between samples.</documentation>
</annotation>
<sequence>
<choice>
<element name="DynamicValue" type="xtce:DynamicValueType">
<annotation>
<documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter.</documentation>
</annotation>
</element>
<element name="DiscreteLookupList" type="xtce:DiscreteLookupListType">
<annotation>
<documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter and selecting a specified value based on tests of the value of that parameter.</documentation>
</annotation>
</element>
</choice>
<element name="LeadingSize" type="xtce:LeadingSizeType" minOccurs="0">
<annotation>
<documentation xml:lang="en">In some string implementations, the size of the string contents (not the memory allocation size) is determined by a leading numeric value. This is sometimes referred to as Pascal strings. If a LeadingSize is specified, then the TerminationChar element does not have a functional meaning.</documentation>
</annotation>
</element>
<element name="TerminationChar" type="hexBinary" default="00" minOccurs="0">
<annotation>
<documentation xml:lang="en">The termination character that represents the end of the string contents. For C and most strings, this is null (00), which is the default.</documentation>
</annotation>
</element>
</sequence>
<attribute name="maxSizeInBits" type="xtce:PositiveLongType" use="required">
<annotation>
<documentation xml:lang="en">The upper bound of the size of this string data type so that the implementation can reserve/allocate enough memory to capture all reported instances of the string.</documentation>
</annotation>
</attribute>
</complexType>
Again, for improved Argument support, a new ArgumentVariableStringType needs to be added before VariableStringType.
New:
<complexType name="ArgumentVariableStringType">
<annotation>
<documentation>Identical to VariableStringType but supports argument instance references.</documentation>
</annotation>
<sequence>
<choice>
<element name="DynamicValue" type="xtce:ArgumentDynamicValueType">
<annotation>
<documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter or argument.</documentation>
</annotation>
</element>
<element name="DiscreteLookupList" type="xtce:ArgumentDiscreteLookupListType">
<annotation>
<documentation xml:lang="en">Determine the container size in bits by interrogating an instance of a parameter or argument and selecting a specified value based on tests of the value of that parameter or argument.</documentation>
</annotation>
</element>
</choice>
<element name="LeadingSize" type="xtce:LeadingSizeType" minOccurs="0">
<annotation>
<documentation xml:lang="en">In some string implementations, the size of the string contents (not the memory allocation size) is determined by a leading numeric value. This is sometimes referred to as Pascal strings. If a LeadingSize is specified, then the TerminationChar element does not have a functional meaning.</documentation>
</annotation>
</element>
<element name="TerminationChar" type="hexBinary" default="00" minOccurs="0">
<annotation>
<documentation xml:lang="en">The termination character that represents the end of the string contents. For C and most strings, this is null (00), which is the default.</documentation>
</annotation>
</element>
</sequence>
<attribute name="maxSizeInBits" type="xtce:PositiveLongType" use="required">
<annotation>
<documentation xml:lang="en">The upper bound of the size of this string data type so that the implementation can reserve/allocate enough memory to capture all reported instances of the string.</documentation>
</annotation>
</attribute>
</complexType>
Boolean Argument/Parameter Info:
The existing BooleanDataType gets improved annotations first.
Before:
<complexType name="BooleanDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Contains a boolean value</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Initial value is always given in calibrated form. </documentation>
<appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo>
</annotation>
</attribute>
<attribute name="oneStringValue" type="string" default="True"/>
<attribute name="zeroStringValue" type="string" default="False"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BooleanDataType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing a boolean data type which has two values only: ‘True’ (1) or ‘False’ (0). The values one and zero may be mapped to a specific string using the attributes oneStringValue and zeroStringValue. This type is a simplified form of the EnumeratedDataType. See BaseDataType, BooleanParameterType and BooleanArgumentType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<attribute name="initialValue" type="string">
<annotation>
<appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
</annotation>
</attribute>
<attribute name="oneStringValue" type="string" default="True">
<annotation>
<documentation xml:lang="en">Enumeration string representing the 1 value, with the default being 'True'.</documentation>
</annotation>
</attribute>
<attribute name="zeroStringValue" type="string" default="False">
<annotation>
<documentation xml:lang="en">Enumeration string representing the 0 value, with the default being 'False'.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
For improved Argument support, a new ArgumentBooleanDataType is added.
Before (does not exist) - add before BooleanDataType:
<complexType name="ArgumentBooleanDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to BooleanDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseDataType">
<attribute name="initialValue" type="string">
<annotation>
<appinfo>Initial value must match either the oneStringValue or the zeroStringValue</appinfo>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
</annotation>
</attribute>
<attribute name="oneStringValue" type="string" default="True">
<annotation>
<documentation xml:lang="en">Enumeration string representing the 1 value, with the default being 'True'.</documentation>
</annotation>
</attribute>
<attribute name="zeroStringValue" type="string" default="False">
<annotation>
<documentation xml:lang="en">Enumeration string representing the 0 value, with the default being 'False'.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
The BooleanDataType is used in the BooleanParameterType, so improve the annotation there as well.
Before:
<complexType name="BooleanParameterType">
<complexContent>
<extension base="xtce:BooleanDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:BooleanAlarmType" minOccurs="0"/>
<element name="ContextAlarmList" type="xtce:BooleanContextAlarmListType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BooleanParameterType">
<annotation>
<documentation xml:lang="en">Describe a boolean parameter type which has two values only: ‘True’ (1) or ‘False’ (0). The values one and zero may be mapped to a specific string using the attributes oneStringValue and zeroStringValue. This type is a simplified form of the EnumeratedDataType. See IntegerDataEncoding and BooleanDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BooleanDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:BooleanAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optionally describe an alarm monitoring specification that is effective whenever a contextual alarm definition does not take precedence.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:BooleanContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optionally describe one or more alarm monitoring specifications that are effective whenever a contextual match definition evaluates to true. The first match that evaluates to true takes precedence.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Update the BooleanArgumentType to incorporate the annotation and utilize the new ArgumentBooleanDataType.
Before:
<complexType name="BooleanArgumentType">
<complexContent>
<extension base="xtce:BooleanDataType"/>
</complexContent>
</complexType>
After:
<complexType name="BooleanArgumentType">
<annotation>
<documentation xml:lang="en">Defines a boolean argument type which has two values only: ‘True’ (1) or ‘False’ (0). The values one and zero may be mapped to a specific string using the attributes oneStringValue and zeroStringValue. This type is a simplified form of the EnumeratedDataType. See IntegerDataEncoding and BooleanDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBooleanDataType"/>
</complexContent>
</complexType>
Enumerated Argument/Parameter Info:
The existing EnumeratedDataType first gets improved annotations.
Before:
<complexType name="EnumeratedDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Contains an enumerated value - a value that has both an integral and a string representation.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<sequence>
<element name="EnumerationList" type="xtce:EnumerationListType"/>
</sequence>
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Initial value is always given in calibrated form.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
After:
<complexType name="EnumeratedDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Describes an enumerated parameter type. The enumeration list consists of label/value pairs. See EnumerationListType, EnumeratedParameterType and EnumeratedArgumentType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<sequence>
<element name="EnumerationList" type="xtce:EnumerationListType">
<annotation>
<documentation xml:lang="en">Unordered list of label/value pairs where values cannot be duplicated.</documentation>
<appinfo>Check that values do not overlap in the mappings.</appinfo>
</annotation>
</element>
</sequence>
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Use the label, it must be in the enumeration list to be valid.</documentation>
<appinfo>Label must be in the enumeration list to be valid.</appinfo>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
To incorporate the improved Argument support, a new ArgumentEnumeratedDataType is now needed.
Before (does not exist) - add before EnumeratedDataType:
<complexType name="ArgumentEnumeratedDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to EnumeratedDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseDataType">
<sequence>
<element name="EnumerationList" type="xtce:EnumerationListType">
<annotation>
<documentation xml:lang="en">Unordered list of label/value pairs where values cannot be duplicated.</documentation>
<appinfo>Check that values do not overlap in the mappings.</appinfo>
</annotation>
</element>
</sequence>
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Use the label, it must be in the enumeration list to be valid.</documentation>
<appinfo>Label must be in the enumeration list to be valid.</appinfo>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Next update the EnumeratedParameterType to improve the annotation. This is where the EnumeratedDataType is used.
Before:
<complexType name="EnumeratedParameterType">
<complexContent>
<extension base="xtce:EnumeratedDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:EnumerationAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state. The default definition applies when there are no context alarm definitions or all the context alarm definitions evaluate to false in their matching criteria.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:EnumerationContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state when another parameter and value combination evaluates to true using the described matching criteria.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="EnumeratedParameterType">
<annotation>
<documentation xml:lang="en">Describe an enumerated parameter type. The enumeration list consists of label/value pairs. See EnumerationListType, IntegerDataEncodingType and EnumeratedDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:EnumeratedDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:EnumerationAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state. The default definition applies when there are no context alarm definitions or all the context alarm definitions evaluate to false in their matching criteria.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:EnumerationContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describe labels for this parameter that should be in an alarm state when another parameter and value combination evaluates to true using the described matching criteria.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
To utilize the new ArgumentEnumeratedDataType, update the EnumeratedArgumentType and improve the annotations.
Before:
<complexType name="EnumeratedArgumentType">
<complexContent>
<extension base="xtce:EnumeratedDataType"/>
</complexContent>
</complexType>
After:
<complexType name="EnumeratedArgumentType">
<annotation>
<documentation xml:lang="en">Describes an enumerated argument type. The enumeration list consists of label/value pairs. See EnumerationListType, IntegerDataEncodingType and EnumeratedDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentEnumeratedDataType"/>
</complexContent>
</complexType>
Binary Argument/Parameter Info:
Next improve the annotations on the BinaryDataType.
Before:
<complexType name="BinaryDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Contains an arbitrarily large binary value </documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<attribute name="initialValue" type="hexBinary">
<annotation>
<documentation xml:lang="en">Extra bits are truncated from the MSB (leftmost)</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BinaryDataType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing a binary data engineering/calibrated type (often called “blob type”). The binary data may be of fixed or variable length, and has an optional encoding and decoding algorithm that may be defined to transform the data between space and ground. See BaseDataType, BinaryParameterType and BinaryArgumentType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<attribute name="initialValue" type="hexBinary">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Extra bits are truncated from the MSB (leftmost).</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Then add a new ArgumentBinaryDataType, again for improved support for Arguments in the schema.
Before (does not exist) - add before BinaryDataType:
<complexType name="ArgumentBinaryDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to BinaryDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseDataType">
<attribute name="initialValue" type="hexBinary">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Extra bits are truncated from the MSB (leftmost).</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Next update the BinaryParameterType for improved annotation.
Before:
<complexType name="BinaryParameterType">
<complexContent>
<extension base="xtce:BinaryDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:AlarmType" minOccurs="0"/>
<element name="BinaryContextAlarmList" type="xtce:BinaryContextAlarmListType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BinaryParameterType">
<annotation>
<documentation xml:lang="en">Describe a binary engineering/calibrated parameter type (sometimes called a “blob type”). It may be of fixed or variable length, and has an optional encoding and decoding algorithm that may be defined to transform the data between space and ground. See BinaryDataEncodingType, IntegerValueType, InputAlgorithmType and BinaryDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BinaryDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:BinaryAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optionally describe an alarm monitoring specification that is effective whenever a contextual alarm definition does not take precedence.</documentation>
</annotation>
</element>
<element name="BinaryContextAlarmList" type="xtce:BinaryContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optionally describe one or more alarm monitoring specifications that are effective whenever a contextual match definition evaluates to true. The first match that evaluates to true takes precedence.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Then update the BinaryArgumentType to utilize the new ArgumentBinaryDataType created above and improve the annotations.
Before:
<complexType name="BinaryArgumentType">
<complexContent>
<extension base="xtce:BinaryDataType"/>
</complexContent>
</complexType>
After:
<complexType name="BinaryArgumentType">
<annotation>
<documentation xml:lang="en">Defines a binary engineering/calibrated argument type (often called “blob type”). The binary data may be of fixed or variable length, and has an optional encoding and decoding algorithm that may be defined to transform the data between space and ground. See BinaryDataEncodingType, IntegerValueType, InputAlgorithmType, and BinaryDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBinaryDataType"/>
</complexContent>
</complexType>
Prior to the BooleanAlarmType, add a new BinaryAlarmType that was missed in previous resolutions.
New:
<complexType name="BinaryAlarmType">
<annotation>
<documentation xml:lang="en">Describe alarm conditions specific to the binary data type, extends the basic AlarmType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:AlarmType"/>
</complexContent>
</complexType>
Integer Argument/Parameter Info:
Improve the annotations for the IntegerDataType.
Before:
<complexType name="IntegerDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Contains an integral value</documentation>
</annotation>
<complexContent>
<extension base="xtce:NumericDataType">
<sequence>
<element name="ValidRange" minOccurs="0">
<annotation>
<documentation xml:lang="en">The Valid Range bounds the universe of possible values this Parameter may have.</documentation>
</annotation>
<complexType>
<complexContent>
<extension base="xtce:IntegerRangeType">
<attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="initialValue" type="long">
<annotation>
<documentation xml:lang="en">Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
</annotation>
</attribute>
<attribute name="sizeInBits" type="xtce:PositiveLongType" default="32"/>
<attribute name="signed" type="boolean" default="true"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="IntegerDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Describe an integer engineering/calibrated data type. Several encodings are supported. See BaseDataType, IntegerParameterType and IntegerArgumentType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<sequence>
<element name="ToString" type="xtce:ToStringType" minOccurs="0">
<annotation>
<documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
</annotation>
</element>
<element name="ValidRange" minOccurs="0">
<annotation>
<documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this parameter. Not to be construed as an alarm definition, violations of the valid range make a parameter value "unreasonable", as opposed to reasonable to be reported, but in a state which should be of concern.</documentation>
</annotation>
<complexType>
<complexContent>
<extension base="xtce:IntegerRangeType">
<attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="initialValue" type="long">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
</annotation>
</attribute>
<attribute name="sizeInBits" type="xtce:PositiveLongType" default="32">
<annotation>
<documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
</annotation>
</attribute>
<attribute name="signed" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">Flag indicating if the engineering/calibrated data type used should support signed representation. This should not be confused with the encoding type for the raw value. The default is true.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Add a new ArgumentIntegerDataType to improve Argument support in the schema.
Before (does not exist) - add before IntegerDataType:
<complexType name="ArgumentIntegerDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to IntegerDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseDataType">
<sequence>
<element name="ToString" type="xtce:ToStringType" minOccurs="0">
<annotation>
<documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
</annotation>
</element>
<element name="ValidRange" minOccurs="0">
<annotation>
<documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this argument. This typically serves to bound user inputs.</documentation>
</annotation>
<complexType>
<complexContent>
<extension base="xtce:IntegerRangeType">
<attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="initialValue" type="xtce:FixedIntegerValueType">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
</annotation>
</attribute>
<attribute name="sizeInBits" type="xtce:PositiveLongType" default="32">
<annotation>
<documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
</annotation>
</attribute>
<attribute name="signed" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">Flag indicating if the engineering/calibrated data type used should support signed representation. This should not be confused with the encoding type for the raw value. The default is true.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
DO NOTHING for the annotations for the IntegerParameterType that uses the IntegerDataType. Already updated in a previous resolution.
Existing:
<complexType name="IntegerParameterType">
<annotation>
<documentation xml:lang="en">Describe an integer parameter type. Several are supported. Calibrated integer to integer relationships should be described with this data type. Use the integer data encoding to define calibrators. Joins float as one of the numerics. See IntegerDataEncoding and IntegerDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:IntegerDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
After:
DO NOT MODIFY
Update the IntegerArgumentType to improve the annotation and use the new ArgumentIntegerDataType from above.
Before:
<complexType name="IntegerArgumentType">
<complexContent>
<extension base="xtce:IntegerDataType">
<sequence>
<element name="ValidRangeSet" type="xtce:ValidIntegerRangeSetType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="IntegerArgumentType">
<annotation>
<documentation xml:lang="en">Describes an integer argument type. Several encodings supported. Calibrated integer to integer relationships should be described with this data type. Use the integer data encoding to define calibrators. Joins float as one of the numerics. See IntegerDataEncoding and IntegerDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentIntegerDataType">
<sequence>
<element name="ValidRangeSet" type="xtce:ValidIntegerRangeSetType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Provides additional platform/program specific ranging information.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Float Argument/Parameter Info:
Update the annotations on the FloatDataType. This also effectively deprecates NumericDataType as it is removed from Float and Integer here and in the resolution above.
Before:
<complexType name="FloatDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Contains a floating point value</documentation>
</annotation>
<complexContent>
<extension base="xtce:NumericDataType">
<sequence>
<element name="ValidRange" minOccurs="0">
<annotation>
<documentation xml:lang="en">The Valid Range bounds the universe of possible values this Parameter may have.</documentation>
</annotation>
<complexType>
<complexContent>
<extension base="xtce:FloatRangeType">
<attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="initialValue" type="double">
<annotation>
<documentation xml:lang="en">Initial value is always given in calibrated form</documentation>
</annotation>
</attribute>
<attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="FloatDataType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing a floating point engineering/calibrated data type. Several encodings are supported. Calibrated integer to float relationships should be described with this data type. Use the data encoding to define calibrators. Joins integer as one of the numerics. See BaseDataType, FloatParameterType and FloatArgumentType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<sequence>
<element name="ToString" type="xtce:ToStringType" minOccurs="0">
<annotation>
<documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
</annotation>
</element>
<element name="ValidRange" minOccurs="0">
<annotation>
<documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this parameter. Not to be construed as an alarm definition, violations of the valid range make a parameter value "unreasonable", as opposed to reasonable to be reported, but in a state which should be of concern.</documentation>
</annotation>
<complexType>
<complexContent>
<extension base="xtce:FloatRangeType">
<attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="initialValue" type="double">
<annotation>
<documentation xml:lang="en">Initial value is always given in calibrated form</documentation>
</annotation>
</attribute>
<attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32">
<annotation>
<documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
For improved Argument support, add a new ArgumentFloatDataType.
Before (does not exist) - add before FloatDataType:
<complexType name="ArgumentFloatDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to FloatDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseDataType">
<sequence>
<element name="ToString" type="xtce:ToStringType" minOccurs="0">
<annotation>
<documentation xml:lang="en">This element provides the implementation with assistance rendering the value as a string for users.</documentation>
</annotation>
</element>
<element name="ValidRange" minOccurs="0">
<annotation>
<documentation xml:lang="en">The Valid Range provides additional boundary/constraint information beyond that of the data encoding in the range of possible values that are meaningful to this argument.</documentation>
</annotation>
<complexType>
<complexContent>
<extension base="xtce:FloatRangeType">
<attribute name="validRangeAppliesToCalibrated" type="boolean" default="true">
<annotation>
<documentation xml:lang="en">By default and general recommendation, the valid range is specified in engineering/calibrated values, although this can be adjusted.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="initialValue" type="double">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form. Default is base 10 form; binary, octal, or hexadecimal values may be given by preceding value with 0[b|B], 0[o|O|, 0[x|X] respectively.</documentation>
</annotation>
</attribute>
<attribute name="sizeInBits" type="xtce:FloatSizeInBitsType" default="32">
<annotation>
<documentation xml:lang="en">Optional hint to the implementation about the size of the engineering/calibrated data type to use internally. Generally this can be determined by examination of the space required to capture the full range of the encoding, but it is not always clear when calibrators are in use. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible values.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Now update the annotations on the FloatParameterType that uses the FloatDataType.
Before:
<complexType name="FloatParameterType">
<complexContent>
<extension base="xtce:FloatDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0"/>
<element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="FloatParameterType">
<annotation>
<documentation xml:lang="en">Describe a floating point parameter type. Several encodings are supported. Calibrated integer to float relationships should be described with this data type. Use the data encoding to define calibrators. Joins integer as one of the numerics. See FloatDataEncodingType, IntegerDataEncodingType and FloatDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:FloatDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:NumericAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:NumericContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Update the FloatArgumentType to use the new ArgumentFloatDataType and improve the annotations.
Before:
<complexType name="FloatArgumentType">
<complexContent>
<extension base="xtce:FloatDataType">
<sequence>
<element name="ValidRangeSet" type="xtce:ValidFloatRangeSetType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="FloatArgumentType">
<annotation>
<documentation xml:lang="en">Describe a floating point argument type. Several encodings are supported. Calibrated integer to float relationships should be described with this data type. Use the data encoding to define calibrators. Joins integer as one of the numerics. See FloatDataEncodingType, IntegerDataEncodingType and FloatDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentFloatDataType">
<sequence>
<element name="ValidRangeSet" type="xtce:ValidFloatRangeSetType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Provides additional platform/program specific ranging information.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
With the change to better tailor the Integer and Float specific data types, the NumericDataType is now no longer used and can be removed from the schema.
SPECIAL: Remove now the NumericDataType and it is no longer used.
String Argument/Parameter Info:
Significant refactoring and clarification have been made to the String defintions. First update the StringDataType annotations.
Before:
<complexType name="StringDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Contains a String Value</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<sequence>
<element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/>
</sequence>
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \",
, etc.) escape sequences.</documentation>
</annotation>
</attribute>
<attribute name="restrictionPattern" type="string">
<annotation>
<documentation xml:lang="en">restriction pattern is a regular expression</documentation>
</annotation>
</attribute>
<attribute name="characterWidth" type="xtce:CharacterWidthType"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="StringDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Defines a base schema type for StringParameterType and StringArgumentType, adding initial value, restriction pattern, character width, and size range in characters. The initial value if set is the initial value of all instances of the child types. The restriction pattern is a regular expression enforcing the string value to this pattern. The character width is on the local data type side. And the size range in character restricts the character set. For telemetered values, if the restriction pattern of size range in character is not met, the item is invalid. See BaseDataType, StringParameterType, StringArgumentType, CharacterWidthType and IntegerRangeType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseDataType">
<sequence>
<element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0">
<annotation>
<documentation xml:lang="en">The size in bits may be greater than or equal to minInclusive. It may be less than or equal to maxInclusive. They both may be set indicating a closed range.</documentation>
</annotation>
</element>
</sequence>
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \",
, etc.) escape sequences.</documentation>
</annotation>
</attribute>
<attribute name="restrictionPattern" type="string">
<annotation>
<documentation xml:lang="en">restriction pattern is a regular expression</documentation>
</annotation>
</attribute>
<attribute name="characterWidth" type="xtce:CharacterWidthType"/>
</extension>
</complexContent>
</complexType>
For improved Argument support, add a new ArgumentStringDataType to the schema.
Before (does not exist) - add before StringDataType:
<complexType name="ArgumentStringDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to StringDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseDataType">
<sequence>
<element name="SizeRangeInCharacters" type="xtce:IntegerRangeType" minOccurs="0"/>
</sequence>
<attribute name="initialValue" type="string">
<annotation>
<documentation xml:lang="en">Initial values for string types, may include C language style (\n, \t, \",
, etc.) escape sequences.</documentation>
</annotation>
</attribute>
<attribute name="restrictionPattern" type="string">
<annotation>
<documentation xml:lang="en">restriction pattern is a regular expression</documentation>
</annotation>
</attribute>
<attribute name="characterWidth" type="xtce:CharacterWidthType"/>
</extension>
</complexContent>
</complexType>
Update the StringParameterType to improve the annotations.
Before:
<complexType name="StringParameterType">
<complexContent>
<extension base="xtce:StringDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:StringAlarmType" minOccurs="0"/>
<element name="ContextAlarmList" type="xtce:StringContextAlarmListType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="StringParameterType">
<annotation>
<documentation xml:lang="en">Describes a string parameter type. Three forms are supported: fixed length, variable length and variable length using a prefix. See StringDataEncodingType and StringDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:StringDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:StringAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:StringContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Update the StringArgumentType to use the new ArgumentStringDataType and improve the annotations.
Before:
<complexType name="StringArgumentType">
<complexContent>
<extension base="xtce:StringDataType"/>
</complexContent>
</complexType>
After:
<complexType name="StringArgumentType">
<annotation>
<documentation xml:lang="en">Describes a string parameter type. Three forms are supported: fixed length, variable length and variable length using a prefix. See StringDataEncodingType and StringDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentStringDataType"/>
</complexContent>
</complexType>
Aggregate Argument/Parameter Info:
Update the annotations for the Aggregate/Structure data type.
Before:
<complexType name="AggregateDataType" abstract="true">
<annotation>
<documentation>Contains multiple values (as members) of any type</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="MemberList" type="xtce:MemberListType"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="AggregateDataType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing a complex data type analogous to a C-struct. Each field of the data type is called a Member. Each Member is part of the MemberList which forms the list of items to be placed under this data type’s name. The MemberList defines a data block and block’s size is defined by the DataEncodings of each Member’s type reference. The data members are ordered and contiguous in the MemberList element (packed). Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, AggregateParameterType and AggregateArgumentType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="MemberList" type="xtce:MemberListType">
<annotation>
<documentation xml:lang="en">Ordered list of the members of the aggregate/structure. Members are contiguous.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Improve the annotation content for the AggregateParameterType type.
Before:
<complexType name="AggregateParameterType">
<annotation>
<documentation xml:lang="en">AggegateParameters are analogous to a C struc, they are an aggregation of related data items. Each of these data items is defined here as a 'Member' </documentation>
</annotation>
<complexContent>
<extension base="xtce:AggregateDataType"/>
</complexContent>
</complexType>
After:
<complexType name="AggregateParameterType">
<annotation>
<documentation xml:lang="en">Describe a complex data type analogous to a C-struct. Each field of the data type is called a Member. Each Member is part of the MemberList which forms the list of items to be placed under this data type’s name. The MemberList defines a data block and block’s size is defined by the DataEncodings of each Member’s type reference. The data members are ordered and contiguous in the MemberList element (packed). Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, and AggregateDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:AggregateDataType"/>
</complexContent>
</complexType>
Improve the annotation content for the AggregateArgumentType type.
Before:
<complexType name="AggregateArgumentType">
<complexContent>
<extension base="xtce:AggregateDataType"/>
</complexContent>
</complexType>
After:
<complexType name="AggregateArgumentType">
<annotation>
<documentation xml:lang="en">Describe a complex data type analogous to a C-struct. Each field of the data type is called a Member. Each Member is part of the MemberList which forms the list of items to be placed under this data type’s name. The MemberList defines a data block and block’s size is defined by the DataEncodings of each Member’s type reference. The data members are ordered and contiguous in the MemberList element (packed). Each member may be addressed by the dot syntax similar to C such as P.voltage if P is the referring parameter and voltage is of a member of P’s aggregate type. See MemberType, MemberListType, DataEncodingType, NameReferenceType, and AggregateDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:AggregateDataType"/>
</complexContent>
</complexType>
Relative Time Argument/Parameter Info:
DO NOTHING for the annotations for the RelativeTimeDataType that uses the BaseTimeDataType. Already updated in a previous resolution.
Before:
<complexType name="RelativeTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. </documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseTimeDataType">
<attribute name="initialValue" type="duration"/>
</extension>
</complexContent>
</complexType>
After:
DO NOT MODIFY
For improved Argument support, add a new ArgumentRelativeTimeDataType.
Before (does not exist) - add after RelativeTimeDataType:
<complexType name="ArgumentRelativeTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. </documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseTimeDataType">
<attribute name="initialValue" type="duration"/>
</extension>
</complexContent>
</complexType>
Improve and clarify the annotations for the RelativeTimeParameterType.
Before:
<complexType name="RelativeTimeParameterType">
<complexContent>
<extension base="xtce:RelativeTimeDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:TimeAlarmType" minOccurs="0"/>
<element name="ContextAlarmList" type="xtce:TimeContextAlarmListType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="RelativeTimeParameterType">
<annotation>
<documentation xml:lang="en">Describes a relative time parameter type. Relative time parameters are time offsets (e.g. 10 second, 1.24 milliseconds, etc.) See IntegerDataEncodingType, FloatDataEncoding and RelativeTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:RelativeTimeDataType">
<sequence>
<element name="DefaultAlarm" type="xtce:TimeAlarmType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Default alarm definitions are those which do not adjust definition logic based on the value of other parameters. Other parameters may participate in the determination of an alarm condition for this parameter, but the definition logic of the alarm on this parameter is constant. If the alarming logic on this parameter changes based on the value of other parameters, then it is a ContextAlarm and belongs in the ContextAlarmList element.</documentation>
</annotation>
</element>
<element name="ContextAlarmList" type="xtce:TimeContextAlarmListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Context alarm definitions are those which adjust the definition logic for this parameter based on the value of other parameters. A context which evaluates to being in effect, based on the testing of another parameter, takes precedence over the default alarms in the DefaultAlarm element. If the no context alarm evaluates to being in effect, based on the testing of another parameter, then the default alarm definitions from the DefaultAlarm element will remain in effect. If multiple contexts evaluate to being in effect, then the first one that appears will take precedence.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Update the RelativeTimeArgumentType to utilize the new ArgumentRelativeTimeDataType and improve the annotation.
Before:
<complexType name="RelativeTimeArgumentType">
<complexContent>
<extension base="xtce:RelativeTimeDataType"/>
</complexContent>
</complexType>
After:
<complexType name="RelativeTimeArgumentType">
<annotation>
<documentation xml:lang="en">Describes a relative time argument type. Relative time parameters are time offsets (e.g. 10 second, 1.24 milliseconds, etc.) See IntegerDataEncodingType, FloatDataEncoding and RelativeTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentRelativeTimeDataType"/>
</complexContent>
</complexType>
Absolute Time Argument/Parameter Info:
Update the BaseTimeDataType to improve annotation and add a previously missed baseType attribute.
Before:
<complexType name="BaseTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">An abstract type used by within the schema to describe derive other data types by the ground system. </documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<sequence minOccurs="0">
<element name="Encoding" type="xtce:EncodingType"/>
</sequence>
<sequence minOccurs="0">
<element name="ReferenceTime" type="xtce:ReferenceTimeType"/>
</sequence>
</sequence>
</extension>
</complexContent>
</complexType>
After:
<complexType name="BaseTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">An abstract schema type used within the schema to derive other time based data types: RelativeTimeDataType and AbsoluteTimeDataType. An absolute time data type is a telemetered source/destination data type. A data encoding must be set. An optional epoch may be set. Time types are an exception to other primitives because, if the time data type is not telemetered, it still must have a data encoding set. See DataEncodingType, AbsoluteTimeDataType and RelativeTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="Encoding" type="xtce:EncodingType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describes how the raw base counts of the time type are encoded/decoded.</documentation>
</annotation>
</element>
<element name="ReferenceTime" type="xtce:ReferenceTimeType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describes origin (epoch or reference) of this time type.</documentation>
</annotation>
</element>
</sequence>
<attribute name="baseType" type="xtce:NameReferenceType">
<annotation>
<documentation xml:lang="en">Extend another absolute or relative time type.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Add a new ArgumentBaseTimeDataType for improved Argument support in the schema.
Before (does not exist) - add before BaseTimeDataType:
<complexType name="ArgumentBaseTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Identical to BaseTimeDataType but supports argument instance references.</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="Encoding" type="xtce:EncodingType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describes how the raw base counts of the time type are encoded/decoded.</documentation>
</annotation>
</element>
<element name="ReferenceTime" type="xtce:ReferenceTimeType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Describes origin (epoch or reference) of this time type.</documentation>
</annotation>
</element>
</sequence>
<attribute name="baseType" type="xtce:NameReferenceType">
<annotation>
<documentation xml:lang="en">Extend another absolute or relative time type.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Update the AbsoluteTimeDataType to improve and clarify the annotation.
Before:
<complexType name="AbsoluteTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">Used to contain an absolute time. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported.
</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseTimeDataType">
<attribute name="initialValue" type="dateTime"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="AbsoluteTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing an absolute time data type. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See AbsoluteTimeParameterType and AbsoluteTimeArgumentType. See AbsouteTimeParameterType, AbsoluteTimeArgumentType and BaseTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:BaseTimeDataType">
<attribute name="initialValue" type="dateTime">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Add a new ArgumentAbsoluteTimeDataType for improved Argument support in the schema using the new ArgumentBaseTimeDataType.
Before (does not exist) - add before AbsoluteTimeDataType:
<complexType name="ArgumentAbsoluteTimeDataType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing an absolute time data type. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See AbsoluteTimeParameterType and AbsoluteTimeArgumentType. See AbsouteTimeParameterType, AbsoluteTimeArgumentType and BaseTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentBaseTimeDataType">
<attribute name="initialValue" type="dateTime">
<annotation>
<documentation xml:lang="en">Default/Initial value is always given in calibrated form.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Update the annotations on the AbsoluteTimeParameterType.
Before:
<complexType name="AbsoluteTimeParameterType">
<complexContent>
<extension base="xtce:AbsoluteTimeDataType"/>
</complexContent>
</complexType>
After:
<complexType name="AbsoluteTimeParameterType">
<annotation>
<documentation xml:lang="en">Describe an absolute time parameter type relative to a known epoch (such as TAI). The string representation of this time should use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See TAIType, IntegerDataEncoding and AbsoluteTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:AbsoluteTimeDataType"/>
</complexContent>
</complexType>
Update the annotations and apply the new ArgumentAbsoluteTimeDataType to the AbsoluteTimeArgumentType.
Before:
<complexType name="AbsoluteTimeArgumentType">
<complexContent>
<extension base="xtce:AbsoluteTimeDataType"/>
</complexContent>
</complexType>
After:
<complexType name="AbsoluteTimeArgumentType">
<annotation>
<documentation xml:lang="en">Describe an absolute time argument type relative to a known epoch (such as TAI). The string representation of this time should use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e. the format ss.ss... with any number of digits after the decimal point is supported. See TAIType, IntegerDataEncoding and AbsoluteTimeDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArgumentAbsoluteTimeDataType"/>
</complexContent>
</complexType>
Array Argument/Parameter Info:
Improve the annotations for arrays by updating the ArrayDataTypeType.
Before:
<complexType name="ArrayDataTypeType" abstract="true">
<annotation>
<documentation xml:lang="en">An array of values of the type referenced in 'arrayTypeRef' and have the number of array dimensions as specified in 'numberOfDimensions' </documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<sequence>
<element name="DimensionList" type="xtce:DimensionListType"/>
</sequence>
<attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required"/>
</extension>
</complexContent>
</complexType>
After:
<complexType name="ArrayDataTypeType" abstract="true">
<annotation>
<documentation xml:lang="en">A base schema type for describing an array data type. The number of and size of each dimension is defined in its two child types. See NameReferenceType, ArrayArgumentType and ArrayParameterType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:NameDescriptionType">
<attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required">
<annotation>
<documentation xml:lang="en">Reference to the data type that represents the type of the elements for this array.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>
Follow up with improved array annotation by updating the ArrayParameterType type.
Before:
<complexType name="ArrayParameterType">
<annotation>
<documentation>Describe an array parameter type. The size and number of dimensions are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArrayDataTypeType"/>
</complexContent>
</complexType>
After:
<complexType name="ArrayParameterType">
<annotation>
<documentation xml:lang="en">Describe an array parameter type. The size and number of dimensions are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArrayDataTypeType">
<sequence>
<element name="DimensionList" type="xtce:DimensionListType">
<annotation>
<documentation xml:lang="en">Describe the dimensions of this array.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Also update the annotations for the ArrayArgumentType type and take into account the ArgumentDimensionListType added in a previous resolution.
Before:
<complexType name="ArrayArgumentType">
<annotation>
<documentation>Describe an array argument type. The size and number of dimension are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArrayDataTypeType"/>
</complexContent>
</complexType>
After:
<complexType name="ArrayArgumentType">
<annotation>
<documentation xml:lang="en">Describe an array argument type. The size and number of dimension are described here. See ArrayParameterRefEntryType, NameReferenceType and ArrayDataType.</documentation>
</annotation>
<complexContent>
<extension base="xtce:ArrayDataTypeType">
<sequence>
<element name="DimensionList" type="xtce:ArgumentDimensionListType">
<annotation>
<documentation xml:lang="en">Describe the dimensions of this array.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
Now to the ParameterTypeSet and ArgumentTypeSet. Improve the annotations on these lists.
Before:
<complexType name="ParameterTypeSetType">
<annotation>
<documentation xml:lang="en">Holds the list of parameter type definitions. A Parameter is a description of something that can have a value; it is not the value itself. </documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="StringParameterType" type="xtce:StringParameterType"/>
<element name="EnumeratedParameterType" type="xtce:EnumeratedParameterType"/>
<element name="IntegerParameterType" type="xtce:IntegerParameterType"/>
<element name="BinaryParameterType" type="xtce:BinaryParameterType"/>
<element name="FloatParameterType" type="xtce:FloatParameterType"/>
<element name="BooleanParameterType" type="xtce:BooleanParameterType"/>
<element name="RelativeTimeParameterType" type="xtce:RelativeTimeParameterType"/>
<element name="AbsoluteTimeParameterType" type="xtce:AbsoluteTimeParameterType"/>
<element name="ArrayParameterType" type="xtce:ArrayParameterType"/>
<element name="AggregateParameterType" type="xtce:AggregateParameterType"/>
</choice>
</complexType>
After:
<complexType name="ParameterTypeSetType">
<annotation>
<documentation xml:lang="en">Describe an unordered collection of parameter type definitions. These types named for the engineering/calibrated type of the parameter. See BaseDataType and BaseTimeDataType.</documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="StringParameterType" type="xtce:StringParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a character string.</documentation>
</annotation>
</element>
<element name="EnumeratedParameterType" type="xtce:EnumeratedParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an enumeration.</documentation>
</annotation>
</element>
<element name="IntegerParameterType" type="xtce:IntegerParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an integer.</documentation>
</annotation>
</element>
<element name="BinaryParameterType" type="xtce:BinaryParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a binary (usually hex represented).</documentation>
</annotation>
</element>
<element name="FloatParameterType" type="xtce:FloatParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a decimal.</documentation>
</annotation>
</element>
<element name="BooleanParameterType" type="xtce:BooleanParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a boolean enumeration.</documentation>
</annotation>
</element>
<element name="RelativeTimeParameterType" type="xtce:RelativeTimeParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a duration in time.</documentation>
</annotation>
</element>
<element name="AbsoluteTimeParameterType" type="xtce:AbsoluteTimeParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an instant in time.</documentation>
</annotation>
</element>
<element name="ArrayParameterType" type="xtce:ArrayParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of an array of a primitive type.</documentation>
</annotation>
</element>
<element name="AggregateParameterType" type="xtce:AggregateParameterType">
<annotation>
<documentation xml:lang="en">Describe a parameter type that has an engineering/calibrated value in the form of a structure of parameters of other types.</documentation>
</annotation>
</element>
</choice>
</complexType>
Before:
<complexType name="ArgumentTypeSetType">
<annotation>
<documentation xml:lang="en">Holds the list of argument type definitions. </documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="StringArgumentType" type="xtce:StringArgumentType"/>
<element name="EnumeratedArgumentType" type="xtce:EnumeratedArgumentType"/>
<element name="IntegerArgumentType" type="xtce:IntegerArgumentType"/>
<element name="BinaryArgumentType" type="xtce:BinaryArgumentType"/>
<element name="FloatArgumentType" type="xtce:FloatArgumentType"/>
<element name="BooleanArgumentType" type="xtce:BooleanArgumentType"/>
<element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType"/>
<element name="AbsoluteTimeArgumentType" type="xtce:AbsoluteTimeArgumentType"/>
<element name="ArrayArgumentType" type="xtce:ArrayArgumentType"/>
<element name="AggregateArgumentType" type="xtce:AggregateArgumentType"/>
</choice>
</complexType>
After:
<complexType name="ArgumentTypeSetType">
<annotation>
<documentation xml:lang="en">Describe an unordered collection of argument type definitions. These types named for the engineering/calibrated type of the argument. See BaseDataType and BaseTimeDataType.</documentation>
</annotation>
<choice maxOccurs="unbounded">
<element name="StringArgumentType" type="xtce:StringArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a character string.</documentation>
</annotation>
</element>
<element name="EnumeratedArgumentType" type="xtce:EnumeratedArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an enumeration.</documentation>
</annotation>
</element>
<element name="IntegerArgumentType" type="xtce:IntegerArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an integer.</documentation>
</annotation>
</element>
<element name="BinaryArgumentType" type="xtce:BinaryArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a binary (usually hex represented).</documentation>
</annotation>
</element>
<element name="FloatArgumentType" type="xtce:FloatArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a decimal.</documentation>
</annotation>
</element>
<element name="BooleanArgumentType" type="xtce:BooleanArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a boolean enumeration.</documentation>
</annotation>
</element>
<element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a duration in time.</documentation>
</annotation>
</element>
<element name="AbsoluteTimeArgumentType" type="xtce:AbsoluteTimeArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an instant in time.</documentation>
</annotation>
</element>
<element name="ArrayArgumentType" type="xtce:ArrayArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of an array of a primitive type.</documentation>
</annotation>
</element>
<element name="AggregateArgumentType" type="xtce:AggregateArgumentType">
<annotation>
<documentation xml:lang="en">Describe an argument type that has an engineering/calibrated value in the form of a structure of arguments of other types.</documentation>
</annotation>
</element>
</choice>
</complexType>
After addition of these changes and the previous few issue resolutions, the following types should be deleted because they are no longer used in the schema:
FixedValueEntryType (renamed earlier for consistency)
ArgumentInstanceType (refactored out)
ArgumentRefEntryType (renamed earlier for consistency)
ArrayArgumentRefEntryType (renamed earlier for consistency)
)</documentation>