XTCE 1.2 RTF Avatar
  1. OMG Issue

XTCE12 — ValidRange element duplicated with ValidRangeSet in ArgumentTypeSet

  • Key: XTCE12-456
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    There appears to be a duplication mistake in the CommandMetaData ArgumentTypeSet. Two of the Argument Types (Integer and Float) have both a ValidRange element and a ValidRangeSet/ValidRange element.

    It is probably not necessary to have both. The single ValidRange should be fine. To define multiple ValidRanges introduces an opportunity for mismatch. If uncalibrated and calibrated ValidRange values exist, they should be converted to one or the other.

  • Reported: XTCE 1.1 — Sat, 3 Jun 2017 17:27 GMT
  • Disposition: Resolved — XTCE 1.2
  • Disposition Summary:

    Propose to incorporate the consensus updates for ValidRangeSet in Argument types

    We recognize that the ValidRange and ValidRangeSet elements in the Float and Integer Argument Types in MetaCommand are confusing and seemingly redundant.

    To correct this, a consensus has arrived on removing the singleton ValidRange element and providing better explanation inside of ValidRangeSet on the usage, especially where multiple sequential ValidRange elements are present.

    The existing two types affected currently appear as:

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

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

    First step is to remove the definition of the ValidRange elements from the two type definitions above. This results in the following modification to be applied to the schema by replacing the existing types with:

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

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

    The next step in the change is to update the annotations in the ValidFloatRangeSetType and ValidIntegerRangeSetType definitions. The existing definitions are:

    <complexType name="ValidFloatRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. Used to further bound argument values inside the ValidRange for the overall Data Type</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:FloatRangeType" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </complexType>

    <complexType name="ValidIntegerRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. Used to further bound argument values inside the ValidRange for the overall Data Type</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:IntegerRangeType" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="validRangeAppliesToCalibrated" type="boolean" default="true"/>
    </complexType>

    The updated definition below replaces the existing definition:

    <complexType name="ValidFloatRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. A single range is the most common, although it is possible to define multiple ranges when the valid values are not contiguous.</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:FloatRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A valid range constrains the whole set of possible values that could be encoded by the data type to a more "valid" or "reasonable" set of values. This should be treated as a boundary check in an implementation to validate the input or output value. Typically, only 1 range is used. In cases where multiple ranges are used, then the value is valid when it is valid in any of the provided ranges. Implementations may also use these ranges to enhance user interface displays and other visualization widgets as appropriate for the type.</documentation>
    </annotation>
    </element>
    </sequence>
    <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>
    </complexType>

    <complexType name="ValidIntegerRangeSetType">
    <annotation>
    <documentation xml:lang="en">Numerical ranges that define the universe of valid values for this argument. A single range is the most common, although it is possible to define multiple ranges when the valid values are not contiguous.</documentation>
    </annotation>
    <sequence>
    <element name="ValidRange" type="xtce:IntegerRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A valid range constrains the whole set of possible values that could be encoded by the data type to a more "valid" or "reasonable" set of values. This should be treated as a boundary check in an implementation to validate the input or output value. Typically, only 1 range is used. In cases where multiple ranges are used, then the value is valid when it is valid in any of the provided ranges. Implementations may also use these ranges to enhance user interface displays and other visualization widgets as appropriate for the type.</documentation>
    </annotation>
    </element>
    </sequence>
    <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>
    </complexType>

  • Updated: Tue, 10 Jul 2018 14:23 GMT