XML Telemetric & Command Exchange Format Avatar
  1. OMG Specification

XML Telemetric & Command Exchange Format — Closed Issues

  • Acronym: XTCE
  • Issues Count: 89
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE13-197 Text in specification is aging and could use some minor edits XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-189 Mistake in AlarmType refactoring XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-191 Missing Alarm Disable Flag XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-195 Another Potential Usability Issue in Draft 1.3 Specification XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-193 Alarm Usability Problem Detected in Final Draft XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-23 Missing a number of changes and enumerations in ErrorDetectCorrectType children XTCE 1.1 XTCE 1.3 Resolved closed
XTCE13-126 reference to aggregate members and arrays XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-176 Yamcs supports json syntax for array and aggregate parameter/args initial value XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-127 Variable string size specification enforces one of DynamicValueType or DiscreteLookupListType XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-177 SpaceSystem can mean multiple things XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-184 Add ArgumentRef to the Verifier Condition element in MetaCommand XTCE 1.2 XTCE 1.3 Duplicate or Merged closed
XTCE13-125 Access to command arguments in transmission constraints and command verifiers XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-135 ParameterToSet/Derivation is set to abstract and should not be XTCE 1.2 XTCE 1.3 Duplicate or Merged closed
XTCE13-162 BinaryEncoding Extension of SequenceContainer Requires SizeInBits Element XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-30 String Encoding Length descriptions needs further clean up XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-128 Data encodings: FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm SizeInBits should be optional XTCE 1.2 XTCE 1.3 Duplicate or Merged closed
XTCE13-114 BaseConditionsType too broad XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-142 Simplify/align alarm severities across OMG specifications XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-145 clarify semantics of context cals (possibly same as context alarms) XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-143 Clarify RepeatEntry's values and what they mean XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-139 Clarify Behavior of Context Alarms Only Containing a Match XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-140 Reconsider if Specific Color Names Should be Referenced XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-155 ArgumentType References Mixed with ParameterTypes in Key XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-129 Non-ASCII characters in XSD annotations cause tooling issues XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-138 Change Alarm Element Bad Attributes XTCE 1.2 XTCE 1.3 Duplicate or Merged closed
XTCE13-73 rangeForm annotation needs work XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-136 RelativeTime's ChangePerSecondRangeAlarm should be a TimeChangesPerSecondAlarmType XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-134 Possible typo of word "difference" instead of "different" XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-130 Invalid schema exception with xerces parser XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-74 Is rangeForm specialization needed for Change and Multi band alarms? XTCE 1.2 XTCE 1.3 Duplicate or Merged closed
XTCE13-115 Disallow duplicate labels in the EnumerationList XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-110 Discrete lookup list has no default (or i don't get it) XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-116 Possible typo of word "encoded" as "endcode" XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-111 CustomAlgorithm needs a language/implementation field XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-34 ArgumentInputSetType is inconsistent with InputSetType XTCE 1.2b1 XTCE 1.3 Resolved closed
XTCE13-112 LinearAdjust -- slope should default to 1 XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-108 BinaryContextAlarmList should be ContextAlarmList XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-32 needs to be updated for items that no longer support hex, octal, binary XTCE 1.2b1 XTCE 1.3 Resolved closed
XTCE13-37 Incorrect MetaCommandRef element definition XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-33 Inconsistency in Argument Types with respect to FixedIntegerValueType XTCE 1.2b1 XTCE 1.3 Duplicate or Merged closed
XTCE13-39 Inconsistent time unit data types XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-71 CNES CCSDS -- unit set "form" question XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-67 CustomAlarmType has wrong parent XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-29 ByteOrderList is invalid for Containers XTCE 1.1 XTCE 1.3 Resolved closed
XTCE13-28 Clean up semantics of "OO-Include Condition" XTCE 1.1 XTCE 1.3 Closed; No Change closed
XTCE13-70 CNES CCSDS -- inside/outside range support in ValidRange XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-68 CNES CCSDS -- Time ParameterType inheritance may need to be repolled XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-91 MemberType and ComparisonType annotation misses fix to value formatting XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-31 ServiceRef construction error XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-69 CNES CCSDS -- RelativeTimeAgument typo XTCE 1.2 XTCE 1.3 Duplicate or Merged closed
XTCE13-36 RelativeTimeAgumentType is misspelled XTCE 1.2b1 XTCE 1.3 Resolved closed
XTCE13-66 Unecessary Sequence of choice in AlarmType XTCE 1.2 XTCE 1.3 Resolved closed
XTCE13-35 ArgumentAssigmentList in the MetaCommandStep is misspelled XTCE 1.2b1 XTCE 1.3 Resolved closed
XTCE13-5 Add gap entry to container entry list XTCE 1.1 XTCE 1.3 Closed; No Change closed
XTCE13-40 Duplicated BaseCalibratorType extension XTCE 1.2 XTCE 1.3 Closed; No Change closed
XTCE13-1 Type inheritance missing from Absolute and Relative time data types XTCE 1.1 XTCE 1.3 Closed; No Change closed
XTCE13-22 Spelling error for Arguments in XTCE 1.2 proposed XTCE 1.1 XTCE 1.3 Duplicate or Merged closed
XTCE13-26 Re-evaluate the characterWidth attribute in String types XTCE 1.1 XTCE 1.3 Resolved closed
XTCE13-7 Elevate annotation specifying time string formats to an attributes XTCE 1.1 XTCE 1.3 Closed; No Change closed
XTCE13-12 Add OCL specific Algorithm to XTCE XTCE 1.1 XTCE 1.3 Closed; No Change closed
XTCE13-3 Add switch entry to container entry list XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-2 Expand features to include common industry encodings in StreamsSet XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-4 Provide way to categorize all elements with @name into one or more groups XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-6 Add variable to containers XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-9 Need support for mask alarm XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-8 Add ArgumentTypeSet to MetaCommand XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-10 Re-architect XTCE alarm model XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-11 Should RestrictionCriteria should be assignment not operators for Commanding? XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-13 CustomAlgorithm should be "typed" reference to AlgorithmSet XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-14 Expand NameReference semantics XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-15 Add forward/reverse calibrator metadata XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-16 AbsoluteTime should have Alarms XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-17 Checkwindow not tied to context XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-24 List and List> clean up needed XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-18 Message/IncludeCondition/BaseContainer similarity XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-20 lack of Union construct (MER + ASIST) XTCE 1.0b1 XTCE 1.3 Deferred closed
XTCE13-19 Move Alarms outside of Type Area XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-21 inability to describe sets of limits (alarms) and conversions (polynomials) XTCE 1.0b1 XTCE 1.3 Deferred closed
XTCE13-25 Add event message support XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-27 Cleanup Container EntryList element by deprecating IndirectParameterRefEntry XTCE 1.1 XTCE 1.3 Deferred closed
XTCE13-65 lost annotation in 1.2 inputAlgorithmType schema type rework XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-72 CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-38 Missing default value of dataSource attribute XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-113 parametertype and argumenttype type hiearchies still need work XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-109 Dynamic look up should have integer and float forms XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-124 FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm should be allowed for all data encodings XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-107 Revert change to CalibratorType base type XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-137 FixedValueEntry, maybe it's not as good as it could be XTCE 1.2 XTCE 1.3 Deferred closed
XTCE13-141 Add an optional attribute to ComparisonList to make it all ORs XTCE 1.2 XTCE 1.3 Deferred closed

Issues Descriptions

Text in specification is aging and could use some minor edits

  • Key: XTCE13-197
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The specification document will need minor changes:

    • reflect the 1.3 version and an updated namespace date in the URL
    • add newest OMG member participants for the specification
    • correct some grammatical errors
    • move in the direction of aligning some wording with other space related specifications, most notably those from the CCSDS
  • Reported: XTCE 1.2 — Sun, 16 Feb 2025 18:02 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Propose to freshen the specification document for the 1.3 release

    We propose to freshen the document by addressing the points called out in the issue. See the Revised Text field for the precise before/after changes.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Mistake in AlarmType refactoring

  • Key: XTCE13-189
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    It appears that when several base alarm types were made (BooleanAlarmType, BinaryAlarmType, EnumerationAlarmType, NumericAlarmType, etc) that the BinaryAlarmType did not get completely applied. This only affects the class hierarchy when using a code generator and does not affect user documents.

    This "BinaryContextAlarmType" should have called out xtce:BinaryAlarmType as the extension instead of xtce:AlarmType:

    <complexType name="BinaryContextAlarmType">
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Reported: XTCE 1.2 — Mon, 10 Feb 2025 16:45 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Propose to correct minor class inheritance on BinaryContextAlarmType

    Propose to adjust the following type to leverage the class inheritance that was intended by a previous change. This makes it match the others and does not affect the actual XTCE compliant documents.

    Existing BinaryContextAlarmType:

    <complexType name="BinaryContextAlarmType">
    <complexContent>
    <extension base="xtce:AlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Should be:

    <complexType name="BinaryContextAlarmType">
    <complexContent>
    <extension base="xtce:BinaryAlarmType">
    <sequence>
    <element name="ContextMatch" type="xtce:ContextMatchType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Missing Alarm Disable Flag

  • Key: XTCE13-191
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I have seen a couple vendors now who have a possible flag for enabling/disabling alarm definitions on a per-parameter basis for individual alarms. Currently, XTCE does not have a mechanism for their databases to deliver the default enable/disable state.

  • Reported: XTCE 1.2 — Mon, 10 Feb 2025 23:20 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Add an optional flag to indicate an enable/disable state from the factory for alarms

    A database owner could deliver a flag for an alarm definition to be specified but disabled. This is a fairly simple addition to the XTCE AlarmType schema type.

    While looking at this, it was also noticed that the minConformance attribute should have had a default value of 1, since it is optional and the minViolations attribute also have a default.

    Propose to update the AlarmType definition from:

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

    With the following replacement that adds 1 attribute named "disabled" with a default value of "false". Also adds the default value of 1 to the minConformance attribute:

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

    A diagram showing the alarm evaluation behavior is provided for reviewer reference.

  • Updated: Tue, 1 Jul 2025 15:05 GMT
  • Attachments:

Another Potential Usability Issue in Draft 1.3 Specification

  • Key: XTCE13-195
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    In the SequenceContainer (also CommandContainer) elements, there is a BinaryEncoding element that contains a SizeInBits element. The SizeInBits element is now optional, but it is not an IntegerValueType. It appears there was a user of a non-fixed sizing value in this field. In the draft, this can only be a fixed numeric value.

  • Reported: XTCE 1.2 — Wed, 12 Feb 2025 21:43 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Propose to correct the SizeInBits change in 1.3 draft

    For backwards compatibility, we propose to restore the previous options within the SizeInBits element, but retain the case of the element being optional when using the BinaryEncoding element.

    The post-ballot 16 content of the ContainerBinaryDataEncodingType is:

    <complexType name="ContainerBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe container 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>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes the optional inclusion of an error detection and/or correction algorithm used with this container.</documentation>
    </annotation>
    </element>
    <element name="SizeInBits" type="xtce:PositiveLongType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Number of bits this container occupies on the stream being encoded/decoded. This is only needed to "force" the bit length of the container to be a fixed value. In most cases, the entry list would define the size of the container.</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>
    </complexType>

    Change just the SizeInBits element type of PositiveLongType (above) to IntegerValueType:

    <complexType name="ContainerBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe container 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>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes the optional inclusion of an error detection and/or correction algorithm used with this container.</documentation>
    </annotation>
    </element>
    <element name="SizeInBits" type="xtce:IntegerValueType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Number of bits this container occupies on the stream being encoded/decoded. This is only needed to "force" the bit length of the container to be a fixed value. In most cases, the entry list would define the size of the container.</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>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Alarm Usability Problem Detected in Final Draft

  • Key: XTCE13-193
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Somewhere in the XTCE 1.3 evolution, we lost the optional flag on the choice for AlarmConditions and CustomAlarm within the AlarmType. Lets restore that because these are fallback possibilities that are used if the user does not leverage the more specific alarm definitions provided in the concrete alarm types.

  • Reported: XTCE 1.2 — Tue, 11 Feb 2025 17:42 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Restore the optional flag inside AlarmType

    We wish to restore this to the XTCE 1.2 optional nature so that backwards compatibility is not broken.

    Current AlarmType Definition Post Ballot 15:

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

    Corrected AlarmType (just the choice now has minOccurs="0"):

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

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Missing a number of changes and enumerations in ErrorDetectCorrectType children

  • Key: XTCE13-23
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The reworked XTCE 1.2 from the proposed BitBucket schema has additional checksums (also hashes) and a new XOR element. In addition, there is a missing @parameterRef that should appear to specify the parameter that holds the value. Some systems do not store that so it can be optional.

  • Reported: XTCE 1.1 — Sat, 5 Aug 2017 18:04 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Propose to come back on deferred XTCE 1.2 resolution and enhance

    An update was proposed for XTCE 1.2, but time ran out and nobody applied the change.

    Here we intend to revisit the fix for XTCE 1.3. Much of this is borrowed and updated from the previous proposal in XTCE12-475. Some additional updates have been made based on my implementer's experience.

    Existing Definition of ErrorDetectCorrectType:

    <complexType name="ErrorDetectCorrectType">
    <annotation>
    <documentation>Describe error detection/correction algorithm.</documentation>
    </annotation>
    <choice>
    <element name="Checksum" type="xtce:ChecksumType"/>
    <element name="CRC" type="xtce:CRCType"/>
    <element name="Parity" type="xtce:ParityType"/>
    </choice>
    </complexType>

    Proposed New Definition of ErrorDetectCorrectType:

    Changes:
    1 - Added/Changed Annotation
    2 - Added XOR type
    3 - Made choice unbounded to multiple algorithms can be specified

    <complexType name="ErrorDetectCorrectType">
    <annotation>
    <documentation>Describe CRC, Checksum, Parity, or XOR for error detection and correction algorithm calculation. See CRCType, ChecksumType, ParityType, and XORType.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="Checksum" type="xtce:ChecksumType">
    <annotation>
    <documentation xml:lang="en">Describe checksum or hash function applied to all or part of this container definition.</documentation>
    </annotation>
    </element>
    <element name="CRC" type="xtce:CRCType">
    <annotation>
    <documentation xml:lang="en">Describe a Cyclic Redundancy Check (CRC) algorithm applied to all or part of this container definition.</documentation>
    </annotation>
    </element>
    <element name="XOR" type="xtce:XORType">
    <annotation>
    <documentation xml:lang="en">Describe an "exclusive or" (XOR) checksum applied to all or part of this container definition.</documentation>
    </annotation>
    </element>
    <element name="Parity" type="xtce:ParityType">
    <annotation>
    <documentation xml:lang="en">Describe a parity applied to all or part of this container definition.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    The new type alluded to above needs to be added. Add XORType immediately after ValueEnumerationType:

    <complexType name="XORType">
    <annotation>
    <documentation xml:lang="en">Describe an exclusive or (XOR) checksum definition. See ErrorDetectCorrectType.</documentation>
    </annotation>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType" default="0">
    <annotation>
    <documentation xml:lang="en">An offset of non-zero may be specified to skip some bits against the reference position in the reference attribute.</documentation>
    </annotation>
    </attribute>
    <attribute name="reference" type="xtce:ReferencePointType" default="start">
    <annotation>
    <documentation xml:lang="en">The bits involved in the calculation may start at the beginning or the end of the container.</documentation>
    </annotation>
    </attribute>
    <attribute name="parameterRef" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Reference to the parameter that contains the value of this computed XOR based on this container. This attribute is optional because not all implementations verify (telemetry) or create (telecommand) error control fields using the XTCE definition.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Next update the annotation on the ChecksumType. Existing Definition of ChecksumType:

    <complexType name="ChecksumType">
    <annotation>
    <documentation>Describe checksum information.</documentation>
    </annotation>
    <sequence>
    <element name="InputAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation>Assumed to return the computed checksum.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType"/>
    <attribute name="reference" type="xtce:ReferencePointType" default="start"/>
    <attribute name="name" use="required">
    <annotation>
    <documentation>Qualified list of name checksum algorithms. If custom is chosen, InputAlgorithm must be set.</documentation>
    </annotation>
    <simpleType>
    <restriction base="string">
    <enumeration value="unix_sum"/>
    <enumeration value="sum8"/>
    <enumeration value="sum16"/>
    <enumeration value="sum24"/>
    <enumeration value="sum32"/>
    <enumeration value="fletcher4"/>
    <enumeration value="fletcher8"/>
    <enumeration value="fletcher16"/>
    <enumeration value="fletcher32"/>
    <enumeration value="adler32"/>
    <enumeration value="luhn"/>
    <enumeration value="verhoeff"/>
    <enumeration value="damm"/>
    <enumeration value="custom">
    <annotation>
    <documentation>Document a custom checksum algorithm</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>
    </attribute>
    <attribute name="hashSizeInBits" type="xtce:PositiveLongType"/>
    </complexType>

    Proposed New Definition of ChecksumType:

    1 - Added/Changed annotation
    2 - Added parameterRef attribute

    <complexType name="ChecksumType">
    <annotation>
    <documentation xml:lang="en">Describe checksum or hash function definiton. See ErrorDetectCorrectType.</documentation>
    </annotation>
    <sequence>
    <element name="InputAlgorithm" type="xtce:InputAlgorithmType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Provided to account for an algorithm not otherwise listed by enumeration. Assumed to return the computed checksum.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType" default="0">
    <annotation>
    <documentation xml:lang="en">An offset of non-zero may be specified to skip some bits against the reference position in the reference attribute.</documentation>
    </annotation>
    </attribute>
    <attribute name="reference" type="xtce:ReferencePointType" default="start">
    <annotation>
    <documentation xml:lang="en">The bits involved in the calculation may start at the beginning or the end of the container.</documentation>
    </annotation>
    </attribute>
    <attribute name="name" use="required">
    <annotation>
    <documentation xml:lang="en">Qualified list of named common checksum algorithms. If custom is chosen, InputAlgorithm must be set.</documentation>
    </annotation>
    <simpleType>
    <restriction base="string">
    <enumeration value="unix_sum"/>
    <enumeration value="sum8"/>
    <enumeration value="sum16"/>
    <enumeration value="sum24"/>
    <enumeration value="sum32"/>
    <enumeration value="fletcher4"/>
    <enumeration value="fletcher8"/>
    <enumeration value="fletcher16"/>
    <enumeration value="fletcher32"/>
    <enumeration value="adler32"/>
    <enumeration value="luhn"/>
    <enumeration value="verhoeff"/>
    <enumeration value="damm"/>
    <enumeration value="custom">
    <annotation>
    <documentation xml:lang="en">Document a custom checksum algorithm in the InputAlgorithm element.</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>
    </attribute>
    <attribute name="hashSizeInBits" type="xtce:PositiveLongType">
    <annotation>
    <documentation xml:lang="en">The hashing algorithm may use a larger internal bucket size than the emitted value size in bits captured by the parameterRef attribute.</documentation>
    </annotation>
    </attribute>
    <attribute name="parameterRef" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Reference to the parameter that contains the value of this computed checksum or hash based on this container. This attribute is optional because not all implementations verify (telemetry) or create (telecommand) error control fields using the XTCE definition.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Next update the annotation on the ParityType. Existing Definition of ParityType:

    <complexType name="ParityType">
    <annotation>
    <documentation xml:lang="en">Bit position starts with 'zero'.</documentation>
    </annotation>
    <attribute name="type" type="xtce:ParityFormType" use="required"/>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType" use="required"/>
    <attribute name="reference" type="xtce:ReferencePointType" default="start"/>
    </complexType>

    Proposed New Definition of ParityType:

    1 - Added/Changed annotation
    2 - Made bitsFromReference optional like the other forms
    3 - Added parameterRef attribute

    <complexType name="ParityType">
    <annotation>
    <documentation xml:lang="en">Describe the parity value. See ErrorDetectCorrectType.</documentation>
    </annotation>
    <attribute name="type" type="xtce:ParityFormType" use="required">
    <annotation>
    <documentation xml:lang="en">The parity form.</documentation>
    </annotation>
    </attribute>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType" default="0">
    <annotation>
    <documentation xml:lang="en">An offset of non-zero may be specified to skip some bits against the reference position in the reference attribute.</documentation>
    </annotation>
    </attribute>
    <attribute name="reference" type="xtce:ReferencePointType" default="start">
    <annotation>
    <documentation xml:lang="en">The bits involved in the calculation may start at the beginning or the end of the container.</documentation>
    </annotation>
    </attribute>
    <attribute name="parameterRef" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Reference to the parameter that contains the value of the parity based on this container. This attribute is optional because not all implementations verify (telemetry) or create (telecommand) error control fields using the XTCE definition.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Next update the annotation on the CRCType. Existing Definition of CRCType:

    <complexType name="CRCType">
    <annotation>
    <documentation xml:lang="en">Cyclic Redundancy Check (CRC) definition. The polynomial coefficients for the CRC
    are defined as a truncated hex value. The coefficient for the nth bit of an n-bit CRC will always be 1 and is not
    represented in the truncated hex value. For example, the truncated hex value of CRC-32 (width=32 bits) used in the
    Ethernet specification is 0x04C11DB7, where each non-zero bit of the truncated hex represents a coefficient of 1 in
    the polynomial and the bit position represents the exponent. There may also be an initial remainder "InitRemainder"
    and a final XOR "FinalXOR" to fully specify the CRC. reflectData and reflectRemainder may also be specified to
    reverse the bit order in the incoming data and/or the result.
    </documentation>
    </annotation>
    <sequence>
    <element name="Polynomial" type="hexBinary"/>
    <element name="InitRemainder" type="hexBinary" minOccurs="0"/>
    <element name="FinalXOR" type="hexBinary" minOccurs="0"/>
    </sequence>
    <attribute name="width" type="xtce:PositiveLongType"/>
    <attribute name="reflectData" type="boolean" default="false"/>
    <attribute name="reflectRemainder" type="boolean" default="false"/>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType"/>
    <attribute name="reference" type="xtce:ReferencePointType" default="start"/>
    </complexType>

    Proposed New Definition of CRCType:

    1 - Added/Changed annotation
    2 - Added parameterRef attribute
    3 - Added direction attribute

    <complexType name="CRCType">
    <annotation>
    <documentation xml:lang="en">Cyclic Redundancy Check (CRC) definition. The polynomial coefficients for the CRC are defined as a truncated hex value. The coefficient for the nth bit of an n-bit CRC will always be 1 and is not represented in the truncated hex value. For example, the truncated hex value of CRC-32 (width=32 bits) used in the Ethernet specification is 0x04C11DB7, where each non-zero bit of the truncated hex represents a coefficient of 1 in the polynomial and the bit position represents the exponent. There may also be an initial remainder "InitRemainder" and a final XOR "FinalXOR" to fully specify the CRC. reflectData and reflectRemainder may also be specified to reverse the bit order in the incoming data and/or the result.</documentation>
    </annotation>
    <sequence>
    <element name="Polynomial" type="hexBinary">
    <annotation>
    <documentation xml:lang="en">The polynomial that represents the calculation in hexadecimal form (described at CRCType annotation).</documentation>
    </annotation>
    </element>
    <element name="InitRemainder" type="hexBinary" minOccurs="0" default="00">
    <annotation>
    <documentation xml:lang="en">A hexadecimal digit string specifying the initial value to set in the shift register before computing the CRC.</documentation>
    </annotation>
    </element>
    <element name="FinalXOR" type="hexBinary" minOccurs="0" default="00">
    <annotation>
    <documentation xml:lang="en">A hexadecimal digit string specifying the value to be added to the final shift register value before output.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="width" type="xtce:PositiveLongType" use="required">
    <annotation>
    <documentation xml:lang="en">The width is the number of bits in the shift register, which is not necessarily the number of bits of the parameter holding the value.</documentation>
    </annotation>
    </attribute>
    <attribute name="reflectData" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Endianness of the input data, true=little, false=big.</documentation>
    </annotation>
    </attribute>
    <attribute name="reflectRemainder" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Endianness of the output data, true=little, false=big.</documentation>
    </annotation>
    </attribute>
    <attribute name="direction" type="xtce:BitOrderType" default="mostSignificantBitFirst">
    <annotation>
    <documentation xml:lang="en">The direction to perform the CRC calculation.</documentation>
    </annotation>
    </attribute>
    <attribute name="bitsFromReference" type="xtce:NonNegativeLongType" default="0">
    <annotation>
    <documentation xml:lang="en">An offset of non-zero may be specified to skip some bits against the reference position in the reference attribute.</documentation>
    </annotation>
    </attribute>
    <attribute name="reference" type="xtce:ReferencePointType" default="start">
    <annotation>
    <documentation xml:lang="en">The bits involved in the calculation may start at the beginning or the end of the container.</documentation>
    </annotation>
    </attribute>
    <attribute name="parameterRef" type="xtce:NameReferenceType">
    <annotation>
    <documentation xml:lang="en">Reference to the parameter that contains the value of the CRC based on this container. This attribute is optional because not all implementations verify (telemetry) or create (telecommand) error control fields using the XTCE definition.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Lastly, propose to mark the ErrorDetectCorrect element from the DataEncodingType definition as deprecated. This has the effect of removing the ErrorDetectCorrect element from the encoding types in the Parameter Type and Argument Type elements.

    Existing Definition of DataEncodingType:

    <complexType name="DataEncodingType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Describes how a particular piece of data is sent or received from some non-native, off-platform device. (e.g. a spacecraft)</documentation>
    </annotation>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0"/>
    </sequence>
    <attribute name="bitOrder" type="xtce:BitOrderType" default="mostSignificantBitFirst"/>
    <attribute name="byteOrder" type="xtce:ByteOrderType" default="mostSignificantByteFirst"/>
    </complexType>

    New proposed definition of DataEncodingType:

    <complexType name="DataEncodingType" abstract="true">
    <annotation>
    <documentation xml:lang="en">Describes how a particular piece of data is sent or received from some non-native, off-platform device. (e.g. a spacecraft)</documentation>
    </annotation>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">DEPRECATED: Use the ErrorDetectCorrect element in the container elements instead.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="bitOrder" type="xtce:BitOrderType" default="mostSignificantBitFirst">
    <annotation>
    <documentation xml:lang="en">Describes the bit ordering of the encoded value.</documentation>
    </annotation>
    </attribute>
    <attribute name="byteOrder" type="xtce:ByteOrderType" default="mostSignificantByteFirst">
    <annotation>
    <documentation xml:lang="en">Describes the endianness of the encoded value.</documentation>
    </annotation>
    </attribute>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

reference to aggregate members and arrays

  • Key: XTCE13-126
  • Status: closed  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    The XTCE spec is not very clear on how the aggregate members can be referenced (for example in match criterias). The doc of AggregateParameterType reads:
    "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".

    However the definition of "NameReferenceType" is silent about aggregates and the "." (dot) character is not allowed to be used in a reference (except in the "./" where it denotes "current space system). The reference suggested above "P.voltage" is invalid.

    In some examples over the internet references to aggregate members are found using standard "/" separator. However this is problematic because a reference like "/A/B/C" is ambiguous, could translate into:
    A (space system)/B(space system)/C(parameter name)
    or
    A(space system)/B(parameter name)/C(aggregate member name)

    Suggest to allow dot notation to reference aggregate members. Similarly allow "[idx]" to reference array indices.

    For example a reference "/A/B.C[3]" can be unambiguously understood as:
    A(space system)/B(parameter name).C(aggregate member name of type array) [3] (index in the C array)

    Perhaps NameReferenceType can be made less restrictive or another type can be defined and used in the ParameterRefType definition.

  • Reported: XTCE 1.2 — Fri, 23 Apr 2021 07:38 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Hoping to put a bow on the regex problems

    Given multiple struggle sessions and the assistance of ChatGPT, a revision of the XTCE regular expressions can be proposed to address this issue that has been around since XTCE 1.0.

    To resolve this, we need to consider that there are "names" in XTCE and then there are references to names. Most references, but not all, can include a "SpaceSystem Path". Parameters and Arguments are a special case of reference in that they can reference parameters of array and aggregate (read C structure) types, which have extensions to their naming that leverage brackets and period characters.

    Reference Type Structural Form Notes
    ArgumentRef name + array modifier or aggregate modifier arguments are local to MetaCommand elements
    ArgumentTypeRef optional path + name  
    ParameterRef optional path + name + array modifier or aggregate modifier  
    ParameterTypeRef optional path + name includes typeRef and arrayTypeRef  
    ReturnParmRef optional path + name + array modifier or aggregate modifier  
    ContainerRef optional path + name  
    StreamRef optional path + name  
    MetaCommandRef optional path + name  
    MessageRef optional path + name  
    ServiceRef optional path + name  

    In the existing XTCE schema, names are restricted by the pattern specified in the complexType "NameType". References are restricted by the pattern specified in the complexType "ReferenceType". Going forward, it will be necessary to replace this with four variants (not including the description of NameType below):

    NameType - Captures the names of objects. Defines a basic name where all characters are allowed except '.', '[', ']', ':', '/', and whitespace (previously only space character, whitespace adds tabs to the restriction).

    NameReferenceNoPathType - This is identical to NameType above and is used for references that point to named objects for which path is not an option and array/aggregate typing is not an option. This is not used by the schema.

    ExpandedNameReferenceNoPathType - Defines a reference to a named object where array and aggregate are possibilities, but path is not a possibility. This is used by the argumentName attribute within the ArgumentAssignment element and ArgumentRef variations.

    NameReferenceWithPathType - Defines a reference that can include a path to a named object where array and aggregate are not possible. This is the most common reference. It is used by the ParameterTypeRef, ArgumentTypeRef, baseType attribute, typeRef attribute, arrayTypeRef attribute, spaceSystemAtRisk attribute, scopeToSpaceSystem attribute, triggerContainer attribute, StreamRef, ContainerRef, MetaCommandRef, ServiceRef, and MessageRef variations.

    ExpandedNameReferenceWithPathType - Defines a reference that can include a path to a named object where array and aggregate are possible. This is used by the ParameterRef variations.

    To begin the actual resolution, we first need to update the existing NameType from:

    	<simpleType name="NameType">
    		<annotation>
    			<documentation>Defines a name where all characters are allowed except '.', '[', ']', ':',  ' ', and '/'.  See NameDescriptionType.</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="[^./:\[\] ]+"/>
    		</restriction>
    	</simpleType>
    

    revised:

    Change Summary: Clarifies and corrects whitespace to include both spaces and tabs.

    	<simpleType name="NameType">
    		<annotation>
    			<documentation>Restricts a basic object name in a document where all characters are allowed except '.', '[', ']', ':', '/', and whitespace.  See NameDescriptionType.</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="[^.\[\]:/ \t]+"/>
    		</restriction>
    	</simpleType>
    

    Next step is to remove and replace the simpleType named "NameReferenceType". It is not specific enough.

    Content to delete (and replace next):

    	<simpleType name="NameReferenceType">
    		<annotation>
    			<documentation>Describe a reference to a named item in an XTCE instance document.  The named must be of schema type NameType.  All name references use a Unix style file system name format where the SpaceSystem names form a path in the SpaceSystem tree. The following characters are reserved for the path: '/', '..' and '.' (multiple consecutive '/'s are treated as one).  The path portion is similar to the directory path used in file system names and the path characters have similar meaning (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). There are three overall forms for name references:  absolute path, relative path and just the name.  The first two forms are called qualified name references; the last form is called an unqualified name reference.  The unqualified form refers to an item in the SpaceSystem the reference is used in.  The unqualified form refers to an item in the SpaceSystem the reference is used in.  It is illegal for a name reference to point to no item ("a dangling name reference").</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="/?(([^./:\[\]]+|\.|\.\.)/)*([^./:\[\]]+)+"/>
    		</restriction>
    	</simpleType>
    

    Replace with these 4 simpleType definitions:

    	<simpleType name="NameReferenceNoPathType">
    		<annotation>
    			<documentation xml:lang="en">This is identical to NameType above and is used for references that point to named objects for which path is not an option and array/aggregate typing is not an option.  This is not used by the schema.</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="[^.\[\]:/ \t]+"/>
    		</restriction>
    	</simpleType>
    	<simpleType name="ExpandedNameReferenceNoPathType">
    		<annotation>
    			<documentation xml:lang="en">Defines a reference to a named object where array and aggregate are possibilities, but path is not a possibility.  This is used by the argumentName attribute within the ArgumentAssignment element and ArgumentRef variations.</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="([^\.\[\]:/ \t]+(\[[0-9]+\])*(\.[^\.\[\]:/ \t]+(\[[0-9]+\])*)*)"/>
    		</restriction>
    	</simpleType>
    	<simpleType name="NameReferenceWithPathType">
    		<annotation>
    			<documentation xml:lang="en">Defines a reference that can include a path to a named object where array and aggregate are not possible.  The named must be of schema type NameType.  All name references use a Unix style file system name format where the SpaceSystem names form a path in the SpaceSystem tree. The following characters are reserved for the path: '/', '..' and '.' (multiple consecutive '/'s are treated as one).  The path portion is similar to the directory path used in file system names and the path characters have similar meaning (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). There are three overall forms for name references:  absolute path, relative path and just the name.  The first two forms are called qualified name references; the last form is called an unqualified name reference.  The unqualified form refers to an item in the SpaceSystem the reference is used in.  The unqualified form refers to an item in the SpaceSystem the reference is used in.  All name references must resolve to a named item (i.e. no dangling name references).  This is used by the ParameterTypeRef, ArgumentTypeRef, baseType attribute, typeRef attribute, arrayTypeRef attribute, spaceSystemAtRisk attribute, scopeToSpaceSystem attribute, triggerContainer attribute, StreamRef, ContainerRef, MetaCommandRef, ServiceRef, and MessageRef variations.</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="(/?(|\.{1,2}/|[^.\[\]:/ \t]+))*[^.\[\]:/ \t]+"/>
    		</restriction>
    	</simpleType>
    	<simpleType name="ExpandedNameReferenceWithPathType">
    		<annotation>
    			<documentation xml:lang="en">Defines a reference that can include a path to a named object where array and aggregate are possible.  The named must be of schema type NameType.  All name references use a Unix style file system name format where the SpaceSystem names form a path in the SpaceSystem tree. The following characters are reserved for the path: '/', '..' and '.' (multiple consecutive '/'s are treated as one).  The path portion is similar to the directory path used in file system names and the path characters have similar meaning (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). There are three overall forms for name references:  absolute path, relative path and just the name.  The first two forms are called qualified name references; the last form is called an unqualified name reference.  The unqualified form refers to an item in the SpaceSystem the reference is used in.  The unqualified form refers to an item in the SpaceSystem the reference is used in.  All name references must resolve to a named item (i.e. no dangling name references).  This is used by the ParameterRef variations.</documentation>
    		</annotation>
    		<restriction base="normalizedString">
    			<pattern value="(/?(|\.{1,2}/|[^.\[\]:/ \t]+))*[^.\[\]:/ \t]+([^\.\[\]:/ \t]+(\[[0-9]+\])*(\.[^\.\[\]:/ \t]+(\[[0-9]+\])*)*)*"/>
    		</restriction>
    	</simpleType>
    

    With the above types added, it is then necessary to deploy them to the schema in the places where references are used. Unlike some other resolutions, I will not duplicate entire "simpleType" and "complexType" elements here for context. It is too long. Instead, I will specify the name of the type to be edited and the specific line. In each case, it appears that it would be sufficient for another user to duplicate the work.

    In the ArgumentArrayArgumentRefEntryType, change this line from:

    <attribute name="argumentRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="argumentRef" type="xtce:ExpandedNameReferenceNoPathType" use="required"/>

    In the ArgumentArrayParameterRefEntryType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the ArgumentContainerRefEntryType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the ArgumentContainerSegmentRefEntryType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the ArgumentParameterRefEntryType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the ArgumentParameterSegmentRefEntryType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the ArgumentStreamSegmentEntryType, change this line from:

    <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="streamRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the ArrayParameterRefEntryType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the BaseContainerType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required">

    In the ContainerRefType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required">

    In the ContainerRefEntryType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the ContainerSegmentRefEntryType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the MessageRefType, change this line from:

    <attribute name="messageRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="messageRef" type="xtce:NameReferenceWithPathType" use="required">

    In the ParameterRefEntryType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the ParameterSegmentRefEntryType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the StreamSegmentEntryType, change this line from:

    <attribute name="streamRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="streamRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the RateInStreamWithStreamNameType, change this line from:

    <attribute name="streamRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="streamRef" type="xtce:NameReferenceWithPathType" use="required">

    In the ParameterType, change this line from:

    <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="parameterTypeRef" type="xtce:NameReferenceWithPathType" use="required">

    In the ParameterRefType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the ArgumentAssignmentType, change this line from:

    <attribute name="argumentName" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="argumentName" type="xtce:ExpandedNameReferenceNoPathType" use="required">

    In the ArgumentInstanceRefType, change this line from:

    <attribute name="argumentRef" type="xtce:NameType" use="required">
    to
    <attribute name="argumentRef" type="xtce:ExpandedNameReferenceNoPathType" use="required">

    In the ArgumentType, change this line from:

    <attribute name="argumentTypeRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="argumentTypeRef" type="xtce:NameReferenceWithPathType" use="required">

    In the BaseMetaCommandType, change this line from:

    <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="metaCommandRef" type="xtce:NameReferenceWithPathType" use="required">

    In the MetaCommandSetType, change this line from:

    <element name="MetaCommandRef" type="xtce:NameReferenceType">
    to
    <element name="MetaCommandRef" type="xtce:NameReferenceWithPathType">

    In the MetaCommandStepType, change this line from:

    <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="metaCommandRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the SignificanceType, change this line from:

    <attribute name="spaceSystemAtRisk" type="xtce:NameReferenceType">
    to
    <attribute name="spaceSystemAtRisk" type="xtce:NameReferenceWithPathType">

    In the InterlockType, change this line from:

    <attribute name="scopeToSpaceSystem" type="xtce:NameReferenceType">
    to
    <attribute name="scopeToSpaceSystem" type="xtce:NameReferenceWithPathType">

    In the InputOutputTriggerAlgorithmType, change this line from:

    <attribute name="triggerContainer" type="xtce:NameReferenceType" use="optional">
    to
    <attribute name="triggerContainer" type="xtce:NameReferenceWithPathType" use="optional">

    In the OnContainerUpdateTriggerType, change this line from:

    <attribute name="containerRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="containerRef" type="xtce:NameReferenceWithPathType" use="required">

    In the OnParameterUpdateTriggerType, change this line from:

    <attribute name="parameterRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="parameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required">

    In the TriggeredMathOperationType, change this line from:

    <attribute name="outputParameterRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="outputParameterRef" type="xtce:ExpandedNameReferenceWithPathType" use="required"/>

    In the CustomStreamType, change these two lines from:

    <attribute name="encodedStreamRef" type="xtce:NameReferenceType" use="required"/>
    <attribute name="decodedStreamRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="encodedStreamRef" type="xtce:NameReferenceWithPathType" use="required"/>
    <attribute name="decodedStreamRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the StreamRefType, change this line from:

    <attribute name="streamRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="streamRef" type="xtce:NameReferenceWithPathType" use="required">

    In the ArrayDataTypeType, change this line from:

    <attribute name="arrayTypeRef" type="xtce:NameReferenceType" use="required">
    to
    <attribute name="arrayTypeRef" type="xtce:NameReferenceWithPathType" use="required">

    In the BaseDataType, change this line from:

    <attribute name="baseType" type="xtce:NameReferenceType">
    to
    <attribute name="baseType" type="xtce:NameReferenceWithPathType">

    In the ArgumentBaseDataType, change this line from:

    <attribute name="baseType" type="xtce:NameReferenceType">
    to
    <attribute name="baseType" type="xtce:NameReferenceWithPathType">

    In the ArgumentBaseTimeDataType, change this line from:

    <attribute name="baseType" type="xtce:NameReferenceType">
    to
    <attribute name="baseType" type="xtce:NameReferenceWithPathType">

    In the BaseTimeDataType, change this line from:

    <attribute name="baseType" type="xtce:NameReferenceType">
    to
    <attribute name="baseType" type="xtce:NameReferenceWithPathType">

    In the MemberType, change this line from:

    <attribute name="typeRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="typeRef" type="xtce:NameReferenceWithPathType" use="required"/>

    In the ServiceRefType, change this line from:

    <attribute name="serviceRef" type="xtce:NameReferenceType" use="required"/>
    to
    <attribute name="serviceRef" type="xtce:NameReferenceWithPathType" use="required"/>

    At the conclusion of this, the "NameReferenceType" should no longer exist in the document.

  • Updated: Tue, 1 Jul 2025 15:05 GMT
  • Attachments:

Yamcs supports json syntax for array and aggregate parameter/args initial value

  • Key: XTCE13-176
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Maybe we should align with yamcs

    initial value

    Initial (default) value given to a parameter or command argument.

    Note that this value can be overwritten for specific parameters, or command arguments using a column of the same name in the Commands and Parameters sheets.

    The value must be understandable for the used engineering type.

    For binary, use a hexadecimal notation.

    For booleans, use a value of true or false.

    For arrays, specify a value in JSON format: [-3, -2.4, 5].

    For aggregates, specify a value in JSON format:

    {member1: 1, member2: 2}

    .

  • Reported: XTCE 1.2 — Thu, 7 Nov 2024 16:04 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Update annotation for initialValue

    This proposal adds flexibility in the definition of initial values for Aggregate/Structure Member elements. In addition, it also adds a previously missing functionality to specify initial values for array elements.

    Original definition of ArrayDataTypeType:

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

    Proposed new definition of ArrayDataTypeType:

    (the only change is to add the initialValue attribute)

    <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>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial values for the individual elements of the array may be provided here at the type definition using JSON style array notation (e.g. [1, 2, 3]). It may be multi-dimension, in which case the sequence matches the sequence of the Dimension elements in the DimensionList. When provided here, the initialValue attributes in the type definition specified in attribute arrayTypeRef are ignored.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Original definition of AggregateDataType:

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

    Proposed new definition of AggregateDataType:

    (the only change is to add the initialValue attribute)

    <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>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Initial values for the individual members of the aggregate/structure may be provided here at the type definition using JSON style notation (e.g. '

    { "member1": 2, "member2": "foo" }

    '). When Member elements provide initialValue attributes, they take precedence over these since these are at the type definition level and the Member element acts like a Parameter element. These may also recurse into members that are also aggregates.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Now with the type definition side done, the ParameterType and ArgumentType elements need updates as well.

    Original definition of ParameterType:

    <complexType name="ParameterType">
    <annotation>
    <documentation xml:lang="en">Describe the properties of a telemetry parameter, including its data type (parameter type). The bulk of properties associated with a telemetry parameter are in its parameter type. The initial value specified here, overrides the initial value in the parameter type. A parameter may be local, in which case its parameter type would have no data encodings. Ideally such a definition would also set data source in parameter properties to "local" but the syntax does not enforce this. See BaseDataType, BaseTimeDataType, and NameReferenceType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="ParameterProperties" type="xtce:ParameterPropertiesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Specify additional properties for this Parameter used by the implementation of tailor the behavior and attributes of the Parameter. When not specified, the defaults on the ParameterProperties element attributes are assumed.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Specify the reference to the parameter type from the ParameterTypeSet area using the path reference rules, either local to this SpaceSystem, relative, or absolute.</documentation>
    </annotation>
    </attribute>
    <attribute name="initialValue" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    <appinfo>The value type must match the Parameter type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Proposed new definition of ParameterType:

    (Only the initialValue attribute documentation changed)

    <complexType name="ParameterType">
    <annotation>
    <documentation xml:lang="en">Describe the properties of a telemetry parameter, including its data type (parameter type). The bulk of properties associated with a telemetry parameter are in its parameter type. The initial value specified here, overrides the initial value in the parameter type. A parameter may be local, in which case its parameter type would have no data encodings. Ideally such a definition would also set data source in parameter properties to "local" but the syntax does not enforce this. See BaseDataType, BaseTimeDataType, and NameReferenceType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="ParameterProperties" type="xtce:ParameterPropertiesType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Specify additional properties for this Parameter used by the implementation of tailor the behavior and attributes of the Parameter. When not specified, the defaults on the ParameterProperties element attributes are assumed.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="parameterTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Specify the reference to the parameter type from the ParameterTypeSet area using the path reference rules, either local to this SpaceSystem, relative, or absolute.</documentation>
    </annotation>
    </attribute>
    <attribute name="initialValue" type="string" use="optional">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime, arrays using JSON syntax (e.g. '[1, 3, 4]', and aggregates using JSON syntax '

    {"member1": 1, "member2": "foo"}

    ' ). Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    <appinfo>The value type must match the Parameter type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Original definition of ArgumentType:

    <complexType name="ArgumentType">
    <annotation>
    <documentation xml:lang="en">An Argument has a name and can take on values with the underlying value type described by the ArgumentTypeRef. Describe the properties of a command argument referring to a data type (argument type). The bulk of properties associated with a command argument are in its argument type. The initial value specified here, overrides the initial value in the argument type. See BaseDataType, BaseTimeDataType and NameReferenceType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="argumentTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Specify the reference to the argument type from the ArgumentTypeSet area using the path reference rules, either local to this SpaceSystem, relative, or absolute.</documentation>
    </annotation>
    </attribute>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    <appinfo>The value type must match the Argument type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Proposed new definition of ArgumentType:

    (Only the initialValue attribute documentation changed)

    <complexType name="ArgumentType">
    <annotation>
    <documentation xml:lang="en">An Argument has a name and can take on values with the underlying value type described by the ArgumentTypeRef. Describe the properties of a command argument referring to a data type (argument type). The bulk of properties associated with a command argument are in its argument type. The initial value specified here, overrides the initial value in the argument type. See BaseDataType, BaseTimeDataType and NameReferenceType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <attribute name="argumentTypeRef" type="xtce:NameReferenceType" use="required">
    <annotation>
    <documentation xml:lang="en">Specify the reference to the argument type from the ArgumentTypeSet area using the path reference rules, either local to this SpaceSystem, relative, or absolute.</documentation>
    </annotation>
    </attribute>
    <attribute name="initialValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime, arrays using JSON syntax (e.g. '[1, 3, 4]', and aggregates using JSON syntax '

    {"member1": 1, "member2": "foo"}

    ' ). Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    <appinfo>The value type must match the Argument type</appinfo>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Variable string size specification enforces one of DynamicValueType or DiscreteLookupListType

  • Key: XTCE13-127
  • Status: closed  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    In addition to the clarity issues highlighted by XTCE13-30, the current definition of StringDataEncoding has a major drawback for variable strings: the VariableStringType enforces one of DynamicValueType or DiscreteLookupListType.

    However the size of the string can be very well determined by the other two methods LeadingSize or TerminationChar. Usage of LeadingSize/TerminationChar in combination with the enforced DynamicValueType/DiscreteLookupListType does not make sense when the string fills completely the allocated buffer and so the size of the string determines the size of the buffer.

    In my opinion having a variable size buffer with a variable string inside that buffer is much less common (never heard of it in fact) than having a fixed size buffer with a variable string inside or a variable string with no buffer (the buffer is the string).

    Suggest to make the DynamicValueType/DiscreteLookupListType optional.

  • Reported: XTCE 1.2 — Fri, 30 Apr 2021 07:34 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Refactor optional elements in StringDataEncoding content

    There does appear to be a combination in the issue that XTCE 1.2 does not well support. To address this, some previous required elements were split into two choice groupings in the schema with additional annotation.

    There is a separate, but very similar, type definition each for the TM and TC side of the schema. Each needs to be updated.

    Existing VariableStringType definition:

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

    Update the VariableStringType with the following content:

    <complexType name="VariableStringType">
    <annotation>
    <documentation xml:lang="en">Describe a variable string whose length may change between samples.</documentation>
    </annotation>
    <sequence>
    <choice minOccurs="0">
    <annotation>
    <documentation>Select the method by which the container entry list allocation in bits will be observed while encoding or decoding the container fields.</documentation>
    </annotation>
    <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>
    <choice>
    <annotation>
    <documentation>Select the method by which the string content is encoded or decoded within the container entry list allocation of bits.</documentation>
    </annotation>
    <element name="LeadingSize" type="xtce:LeadingSizeType">
    <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">
    <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>
    </choice>
    </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>

    Then a similar change needs to be made to the existing ArgumentVariableStringType:

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

    Replace with the following type definition:

    <complexType name="ArgumentVariableStringType">
    <annotation>
    <documentation>Identical to VariableStringType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <choice minOccurs="0">
    <annotation>
    <documentation>Select the method by which the container entry list allocation in bits will be observed while encoding or decoding the container fields.</documentation>
    </annotation>
    <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>
    <choice>
    <annotation>
    <documentation>Select the method by which the string content is encoded or decoded within the container entry list allocation of bits.</documentation>
    </annotation>
    <element name="LeadingSize" type="xtce:LeadingSizeType">
    <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">
    <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>
    </choice>
    </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>

    See attached image from XMLSpy for context.

  • Updated: Tue, 1 Jul 2025 15:05 GMT
  • Attachments:

SpaceSystem can mean multiple things

  • Key: XTCE13-177
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    SpaceSystem in XTCE could mean a system/subsystem, a spacecraft, or perhaps a constellation of spacecraft. There should be a tag/attribute that specifies what the SpaceSystem represents. This would help with interpretation by implementing software.

  • Reported: XTCE 1.2 — Mon, 18 Nov 2024 16:40 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Revise add some optional grouping to SpaceSystem element

    It would be useful to allow for implementers and data owners to be able to include information in the emitted XML about the grouping or hierarchy of SpaceSystem elements. This is entirely specific to the project leveraging XTCE, so the committee does not propose any constraints on the values of these two new optional attributes.

    Original definition of SpaceSystemType:

    <complexType name="SpaceSystemType" mixed="false">
    <annotation>
    <documentation xml:lang="en">SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="Header" type="xtce:HeaderType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Header element contains optional descriptive information about this SpaceSystem or the document as a whole when specified at the root SpaceSystem.</documentation>
    </annotation>
    </element>
    <element name="TelemetryMetaData" type="xtce:TelemetryMetaDataType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element contains descriptions of the telemetry created on the space asset/device and sent to other data consumers.</documentation>
    </annotation>
    </element>
    <element name="CommandMetaData" type="xtce:CommandMetaDataType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element contains descriptions of the commands and their associated constraints and verifications that can be sent to the space asset/device.</documentation>
    </annotation>
    </element>
    <element name="ServiceSet" type="xtce:ServiceSetType" minOccurs="0"/>
    <element ref="xtce:SpaceSystem" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Additional SpaceSystem elements may be used like namespaces to segregate portions of the space asset/device into convenient groupings or may be used to specialize a product line generic SpaceSystem to a specific asset instance.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="operationalStatus" type="token" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional descriptive attribute for document owner convenience.</documentation>
    </annotation>
    </attribute>
    <attribute ref="xml:base"/>
    </extension>
    </complexContent>
    </complexType>

    Proposed new definition of SpaceSystemType:

    Two attributes, "systemType" and "assetType" added.

    <complexType name="SpaceSystemType" mixed="false">
    <annotation>
    <documentation xml:lang="en">SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <element name="Header" type="xtce:HeaderType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">The Header element contains optional descriptive information about this SpaceSystem or the document as a whole when specified at the root SpaceSystem.</documentation>
    </annotation>
    </element>
    <element name="TelemetryMetaData" type="xtce:TelemetryMetaDataType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element contains descriptions of the telemetry created on the space asset/device and sent to other data consumers.</documentation>
    </annotation>
    </element>
    <element name="CommandMetaData" type="xtce:CommandMetaDataType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">This element contains descriptions of the commands and their associated constraints and verifications that can be sent to the space asset/device.</documentation>
    </annotation>
    </element>
    <element name="ServiceSet" type="xtce:ServiceSetType" minOccurs="0"/>
    <element ref="xtce:SpaceSystem" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Additional SpaceSystem elements may be used like namespaces to segregate portions of the space asset/device into convenient groupings or may be used to specialize a product line generic SpaceSystem to a specific asset instance.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="systemType" type="xtce:SystemTypeType" default="unknown">
    <annotation>
    <documentation xml:lang="en">Type of the space system. Represents what from a space enterprise this SpaceSystem element represents. See the individual enumeration descriptions in SystemTypeType.</documentation>
    </annotation>
    </attribute>
    <attribute name="assetType" type="string" default="unknown">
    <annotation>
    <documentation xml:lang="en">Broad name for the type of asset, such as spacecraft, aircraft, device, or any other that makes sense for the system.</documentation>
    </annotation>
    </attribute>
    <attribute name="operationalStatus" type="token" use="optional">
    <annotation>
    <documentation xml:lang="en">Optional descriptive attribute for document owner convenience.</documentation>
    </annotation>
    </attribute>
    <attribute ref="xml:base"/>
    </extension>
    </complexContent>
    </complexType>

    With the systemType attribute, it becomes also necessary to add a new simpleType called SystemTypeType to capture the enumerations alluded to in the documentation. This should appear immediately after the SpaceSystemType definition here.

    <simpleType name="SystemTypeType">
    <annotation>
    <documentation xml:lang="en">The type attribute represents what from a space enterprise this SpaceSystem element represents. See the enumerations for specific details. Unknown is the default for backwards compatibility, though it should be avoided in newer documents.</documentation>
    </annotation>
    <restriction base="token">
    <enumeration value="asset">
    <annotation>
    <documentation xml:lang="en">An form of asset monitored and/or controlled by the enterprise that may participate in a larger group and may be subdivided into internal components.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="assetGroup">
    <annotation>
    <documentation xml:lang="en">A grouping of assets that make sense to aggregate together in the data model, such as a fleet or constellation.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="assetComponent">
    <annotation>
    <documentation xml:lang="en">Internal systems of assets permit managing the structure of XTCE documents by decomposing the internal structures of interest to tighten the scope of an individual SpaceSystem element. The XInclude facility is also available at the SpaceSystem element for managing the size of XTCE documents, in addition to the internal organization.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="unknown">
    <annotation>
    <documentation xml:lang="en">The default enumeration is meant for backwards compatibility with earlier versions and should be avoided.</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add ArgumentRef to the Verifier Condition element in MetaCommand

  • Key: XTCE13-184
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Noticed in YAMCS example. YAMCS says XTCE should support ArgumentRefs in MetaCommand/Verifiers. For example from the YAMCS website:

    <xtce:MetaCommand name="cmd_with_verifier4">
    <xtce:ArgumentList>
    <xtce:Argument name="arg1" argumentTypeRef="u32" />
    </xtce:ArgumentList>
    <xtce:CommandContainer name="cmd_with_verifier4">
    <xtce:EntryList>
    <xtce:ArgumentRefEntry argumentRef="arg1" />
    </xtce:EntryList>
    </xtce:CommandContainer>
    <xtce:VerifierSet>
    <xtce:CompleteVerifier>
    <xtce:BooleanExpression>
    <xtce:Condition>
    <!-- This is not valid according to XTCE but we think it should be made part of the standard.
    It achieves the same as the example above without using the false /yamcs/cmd/arg parameter reference. -->
    <xtce:ArgumentInstanceRef argumentRef="arg1" />
    <xtce:ComparisonOperator>==</xtce:ComparisonOperator>
    <xtce:ParameterInstanceRef parameterRef="local_para1" />
    </xtce:Condition>
    </xtce:BooleanExpression>
    <xtce:CheckWindow timeToStartChecking="PT0S" timeToStopChecking="PT1S" />
    </xtce:CompleteVerifier>
    </xtce:VerifierSet>
    </xtce:MetaCommand>

  • Reported: XTCE 1.2 — Thu, 12 Dec 2024 22:19 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    Duplicate of XTCE13-125

    Duplicate XTCE13-125

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Access to command arguments in transmission constraints and command verifiers

  • Key: XTCE13-125
  • Status: closed  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    Sometimes the constraints and/or verifies associated to a command may depend on the value of the arguments of the command sent. For example setting a thermostat to a certain setpoint may have a constraint which will only allow a given setpoint in a specific operational mode.
    A verifier can compare the setpoint sent as command argument with the setpoint known in the spacecraft and received as a TM parameter.

    To achieve this, arguments references should be allowed in the definition of the constraints/verifiers.

    In practice:

    • TransmissionConstraintType should extend the ArgumentMatchCriteriaType (instead of MatchCriteriaType)
    • CommandVerifierType should allow elements of type ArgumentInputAlgorithmType , ArgumentBooleanExpressionType and ArgumentComparisonType (instead of the non argument variety)

    All the Argument* types are superset of the corresponding non-argument types so by doing this change, the schema will be backward compatible.

    Note: a similar request could be argued for ParametrToSetType to allow setting a parameter to a value computed based on the user defined argument of the command. However since there is no ArgumentMathOperationType, no easy solution can be immediately seen without adding extra types.

  • Reported: XTCE 1.2 — Thu, 22 Apr 2021 08:17 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Reballot: Add Argument Context to Constraints and Verifiers

    It is generally agreed that the transmission constraint and verifiers for the MetaCommand element are of very limited usefulness without having some way to be contextually tied to the argument values of a MetaCommand.

    A couple approaches to solving this problem have been discussed. This approach proposed here introduces a context to these child elements that permits them to be restricted to the value of an argument used in the MetaCommand. This will make these child elements much more useful and also maintain backwards compatibility, which was a concern for some of the other proposed methods.

    To implement this enhancement, first it is necessary to create a new schema type named "ArgumentRestrictionListType". In the supporting XSD file, it is placed above the type named "ArgumentType":

    <complexType name="ArgumentRestrictionListType">
    <annotation>
    <documentation xml:lang="en">Defines a list of argument values that restrict a constraint from being realized in the commanding lifecycle.</documentation>
    </annotation>
    <sequence>
    <element name="ArgumentRestriction" type="xtce:ArgumentAssignmentType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Specifies an argument value that causes this constraint to be realized.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Where the next line is pre-existing:

    <complexType name="ArgumentType">

    Another new schema type named "ArgumentMathOperationType" is introduced next. In the supporting XSD file, it is placed above the type named "MathOperationType":

    <complexType name="ArgumentMathOperationType">
    <annotation>
    <documentation xml:lang="en">Describe a value to set to a destination Parameter after completion of a commanding lifecycle step.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a postfix (aka Reverse Polish Notation (RPN)) expression for mathematical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. For example, the stack, 4 8 /, would result as 0.5. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation>
    </annotation>
    <element name="ValueOperand" type="string">
    <annotation>
    <documentation xml:lang="en">Use a constant in the calculation.</documentation>
    </annotation>
    </element>
    <element name="ThisParameterOperand" type="string" fixed="">
    <annotation>
    <documentation xml:lang="en">Use the value of the target parameter in the calculation. It is the calibrated/engineering value only. If the raw value is needed, specify it explicitly using ParameterInstanceRefOperand. Note this element has no content.</documentation>
    </annotation>
    </element>
    <element name="Operator" type="xtce:MathOperatorsType">
    <annotation>
    <documentation xml:lang="en">All operators utilize operands on the top values in the stack and leaving the result on the top of the stack. Ternary operators utilize the top three operands on the stack, binary operators utilize the top two operands on the stack, and unary operators use the top operand on the stack.</documentation>
    </annotation>
    </element>
    <element name="ParameterInstanceRefOperand" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This element is used to reference the last received/assigned value of any Parameter in this math operation.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRefOperand" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">This element is used to reference a value of any Argument from this command instance in this math operation.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Where the next line is pre-existing:

    <complexType name="MathOperationType" abstract="true">

    This concludes the addition of new schema types, of which there are two above.

    Next, the schema type named "CommandVerifierType" is visited with an addition of a new element that leverages the first new schema type above. The before and after schema type are:

    before change:

    <complexType name="CommandVerifierType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A command verifier is used to check that the command has been successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The CheckWindow is a time period where the verification must test true to pass.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <sequence>
    <choice>
    <element name="ComparisonList" type="xtce:ComparisonListType">
    <annotation>
    <documentation xml:lang="en">Verification is a list of comparisons.</documentation>
    </annotation>
    </element>
    <element name="ContainerRef" type="xtce:ContainerRefType">
    <annotation>
    <documentation xml:lang="en">Verification is a new instance of the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet.</documentation>
    </annotation>
    </element>
    <element name="ParameterValueChange" type="xtce:ParameterValueChangeType">
    <annotation>
    <documentation xml:lang="en">Verification is a telemetry parameter value change on the ground. For example, a command counter.</documentation>
    </annotation>
    </element>
    <element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Verification is outside the scope of regular command and telemetry processing.</documentation>
    </annotation>
    </element>
    <element name="BooleanExpression" type="xtce:BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">Verification is a boolean expression of conditions.</documentation>
    </annotation>
    </element>
    <element name="Comparison" type="xtce:ComparisonType">
    <annotation>
    <documentation xml:lang="en">Verification is a single comparison.</documentation>
    </annotation>
    </element>
    </choice>
    <choice>
    <element name="CheckWindow" type="xtce:CheckWindowType">
    <annotation>
    <documentation xml:lang="en">Define a time window for checking for verification.</documentation>
    </annotation>
    </element>
    <element name="CheckWindowAlgorithms" type="xtce:CheckWindowAlgorithmsType">
    <annotation>
    <documentation xml:lang="en">Define a time window algorithmically for verification.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    After the change, a new "ArgumentRestrictionList" element is added:

    <complexType name="CommandVerifierType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A command verifier is used to check that the command has been successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The CheckWindow is a time period where the verification must test true to pass.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:OptionalNameDescriptionType">
    <sequence>
    <choice>
    <element name="ComparisonList" type="xtce:ComparisonListType">
    <annotation>
    <documentation xml:lang="en">Verification is a list of comparisons.</documentation>
    </annotation>
    </element>
    <element name="ContainerRef" type="xtce:ContainerRefType">
    <annotation>
    <documentation xml:lang="en">Verification is a new instance of the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet.</documentation>
    </annotation>
    </element>
    <element name="ParameterValueChange" type="xtce:ParameterValueChangeType">
    <annotation>
    <documentation xml:lang="en">Verification is a telemetry parameter value change on the ground. For example, a command counter.</documentation>
    </annotation>
    </element>
    <element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
    <annotation>
    <documentation xml:lang="en">Verification is outside the scope of regular command and telemetry processing.</documentation>
    </annotation>
    </element>
    <element name="BooleanExpression" type="xtce:BooleanExpressionType">
    <annotation>
    <documentation xml:lang="en">Verification is a boolean expression of conditions.</documentation>
    </annotation>
    </element>
    <element name="Comparison" type="xtce:ComparisonType">
    <annotation>
    <documentation xml:lang="en">Verification is a single comparison.</documentation>
    </annotation>
    </element>
    </choice>
    <choice>
    <element name="CheckWindow" type="xtce:CheckWindowType">
    <annotation>
    <documentation xml:lang="en">Define a time window for checking for verification.</documentation>
    </annotation>
    </element>
    <element name="CheckWindowAlgorithms" type="xtce:CheckWindowAlgorithmsType">
    <annotation>
    <documentation xml:lang="en">Define a time window algorithmically for verification.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="ArgumentRestrictionList" type="xtce:ArgumentAssignmentListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional list of argument values that manifest this post-transmission validation parameter value check. When not present, this check applies to all instances of the command.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Another schema type named "ParameterToSetType" is visited with an addition of a new element that leverages the second new schema type above. The before and after schema type are:

    before change:

    <complexType name="ParameterToSetType">
    <annotation>
    <documentation xml:lang="en">Sets a Parameter to a new value (either from a derivation or explicitly) after the command has been verified (all verifications have passed).</documentation>
    <appinfo>Value type must match Parameter type.</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterRefType">
    <choice>
    <element name="Derivation" type="xtce:MathOperationType">
    <annotation>
    <documentation xml:lang="en">Specify a MathOperation to use to set the Parameter value. See MathOperationType.</documentation>
    </annotation>
    </element>
    <element name="NewValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time= xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the Parameter and appropriate for the type.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="setOnVerification" type="xtce:VerifierEnumerationType" default="complete">
    <annotation>
    <documentation xml:lang="en">This attribute provides more specific control over when the Parameter value is set. By default, it is when the command have all verifications complete. See VerifierEnumerationType.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    After the change, the "Derivation" element has a new type definition and updated documentation:

    <complexType name="ParameterToSetType">
    <annotation>
    <documentation xml:lang="en">Sets a Parameter to a new value (either from a derivation or explicitly) after the command has been verified (all verifications have passed).</documentation>
    <appinfo>Value type must match Parameter type.</appinfo>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterRefType">
    <choice>
    <element name="Derivation" type="xtce:ArgumentMathOperationType">
    <annotation>
    <documentation xml:lang="en">Specify a simple algorithm to use to set the target Parameter value. See ArgumentMathOperationType.</documentation>
    </annotation>
    </element>
    <element name="NewValue" type="string">
    <annotation>
    <documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time= xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the Parameter and appropriate for the type.</documentation>
    </annotation>
    </element>
    </choice>
    <attribute name="setOnVerification" type="xtce:VerifierEnumerationType" default="complete">
    <annotation>
    <documentation xml:lang="en">This attribute provides more specific control over when the Parameter value is set. By default, it is when the command have all verifications complete. See VerifierEnumerationType.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    The new "ArgumentRestrictionListType" is used now again to enhance the "TransmissionConstraintType", in addition to the usage in "CommandVerifierType" above.

    Previous type definition:

    <complexType name="TransmissionConstraintType">
    <annotation>
    <documentation xml:lang="en">A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType">
    <attribute name="timeOut" type="xtce:RelativeTimeType">
    <annotation>
    <documentation xml:lang="en">Pause during timeOut, fail when the timeout passes</documentation>
    </annotation>
    <!-- removed for CASTOR: default="PT0S" -->
    </attribute>
    <attribute name="suspendable" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Indicates whether the constraints for a Command may be suspended.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    New type definition with the addition of the sequence of element for "ArgumentRestrictionList":

    <complexType name="TransmissionConstraintType">
    <annotation>
    <documentation xml:lang="en">A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType">
    <sequence>
    <element name="ArgumentRestrictionList" type="xtce:ArgumentAssignmentListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional list of argument values that manifest this pre-transmission constraint parameter value check.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="timeOut" type="xtce:RelativeTimeType">
    <annotation>
    <documentation xml:lang="en">Pause during timeOut, fail when the timeout passes</documentation>
    </annotation>
    <!-- removed for CASTOR: default="PT0S" -->
    </attribute>
    <attribute name="suspendable" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Indicates whether the constraints for a Command may be suspended.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    After this, an enhancement to the documentation for the "TransmissionConstraint" element appears to be useful. Only the documentation is added in "TransmissionConstraintListType":

    Before:

    <complexType name="TransmissionConstraintListType">
    <annotation>
    <documentation xml:lang="en">Appended to the TramsmissionConstraint List of the base command. Constraints are checked in order. </documentation>
    </annotation>
    <sequence>
    <element name="TransmissionConstraint" type="xtce:TransmissionConstraintType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    After:

    <complexType name="TransmissionConstraintListType">
    <annotation>
    <documentation xml:lang="en">Appended to the TramsmissionConstraint List of the base command. Constraints are checked in order. </documentation>
    </annotation>
    <sequence>
    <element name="TransmissionConstraint" type="xtce:TransmissionConstraintType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A constraint that potentially blocks transmission of this command based on parameter values for all instances or optionally limited to only when specified argument values are used in the command.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Proceeding forward, an update to the annotation for the "AcceptedVerifierType" is made to improve reader clarity.

    Previous type definition (only change is in the documentation element):

    <complexType name="AcceptedVerifierType">
    <annotation>
    <documentation xml:lang="en">A verifier that means the SpaceSystem has accepted the command</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    New definition:

    <complexType name="AcceptedVerifierType">
    <annotation>
    <documentation xml:lang="en">A verifier that means the destination has accepted the command.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    The the type definition for "CompleteVerifierType" needs some enhancement because the new restrictions slightly change the behavior when they are present.

    Previous type definition (only change is in the documentation element):

    <complexType name="CompleteVerifierType">
    <annotation>
    <documentation xml:lang="en">A possible set of verifiers that all must be true for the command be considered completed. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType">
    <sequence minOccurs="0">
    <element name="ReturnParmRef" type="xtce:ParameterRefType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    New definition:

    <complexType name="CompleteVerifierType">
    <annotation>
    <documentation xml:lang="en">A possible set of verifiers that all must be true for the command be considered completed. Consider that some may not participate due to argument value restriction, if that element is used.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType">
    <sequence minOccurs="0">
    <element name="ReturnParmRef" type="xtce:ParameterRefType"/>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    An update to the annotation for the "QueuedVerifierType" is made to improve reader clarity.

    Previous type definition (only change is in the documentation element):

    <complexType name="QueuedVerifierType">
    <annotation>
    <documentation xml:lang="en">A verifer that means the command is scheduled for execution by the SpaceSystem.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    New definition:

    <complexType name="QueuedVerifierType">
    <annotation>
    <documentation xml:lang="en">A verifer that means the command is scheduled for execution by the destination.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    An update to the annotation for the "ReceivedVerifierType" is made to improve reader clarity.

    Previous type definition (only change is in the documentation element):

    <complexType name="ReceivedVerifierType">
    <annotation>
    <documentation xml:lang="en">A verifier that simply means the SpaceSystem has received the command.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    New definition:

    <complexType name="ReceivedVerifierType">
    <annotation>
    <documentation xml:lang="en">A verifier that simply means the destination has received the command.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    An update to the annotation for the "SentFromRangeVerifierType" is made to improve reader clarity.

    Previous type definition (only change is in the documentation element):

    <complexType name="SentFromRangeVerifierType">
    <annotation>
    <documentation xml:lang="en">Sent from range means the command has been transmitted to the spacecraft by the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft. </documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    New definition:

    <complexType name="SentFromRangeVerifierType">
    <annotation>
    <documentation xml:lang="en">Sent from range means the command has been transmitted to the spacecraft by the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    An update to the annotation for the "TransferredToRangeVerifierType" is made to improve reader clarity.

    Previous type definition (only change is in the documentation element):

    <complexType name="TransferredToRangeVerifierType">
    <annotation>
    <documentation xml:lang="en">Transferred to range means the command has been received to the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    New definition:

    <complexType name="TransferredToRangeVerifierType">
    <annotation>
    <documentation xml:lang="en">Transferred to range means the command has been received to the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:CommandVerifierType"/>
    </complexContent>
    </complexType>

    Once updating the documentation in the type definitions above, the elements themselves would be improved by adding their annotations in the "VerifierSetType".

    Before:

    <complexType name="VerifierSetType">
    <annotation>
    <documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with different states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple "complete" and "execution" verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the "complete" and "execution" verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>
    </annotation>
    <sequence>
    <element name="TransferredToRangeVerifier" type="xtce:TransferredToRangeVerifierType" minOccurs="0"/>
    <element name="SentFromRangeVerifier" type="xtce:SentFromRangeVerifierType" minOccurs="0"/>
    <element name="ReceivedVerifier" type="xtce:ReceivedVerifierType" minOccurs="0"/>
    <element name="AcceptedVerifier" type="xtce:AcceptedVerifierType" minOccurs="0"/>
    <element name="QueuedVerifier" type="xtce:QueuedVerifierType" minOccurs="0"/>
    <element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded"/>
    <element name="CompleteVerifier" type="xtce:CompleteVerifierType" minOccurs="0" maxOccurs="unbounded"/>
    <element name="FailedVerifier" type="xtce:FailedVerifierType" minOccurs="0"/>
    </sequence>
    </complexType>

    After:

    <complexType name="VerifierSetType">
    <annotation>
    <documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with different states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple "complete" and "execution" verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the "complete" and "execution" verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>
    </annotation>
    <sequence>
    <element name="TransferredToRangeVerifier" type="xtce:TransferredToRangeVerifierType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Transferred to range means the command has been received to the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
    </annotation>
    </element>
    <element name="SentFromRangeVerifier" type="xtce:SentFromRangeVerifierType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Sent from range means the command has been transmitted to the spacecraft by the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
    </annotation>
    </element>
    <element name="ReceivedVerifier" type="xtce:ReceivedVerifierType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A verifier that simply means the destination has received the command.</documentation>
    </annotation>
    </element>
    <element name="AcceptedVerifier" type="xtce:AcceptedVerifierType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A verifier that means the destination has accepted the command.</documentation>
    </annotation>
    </element>
    <element name="QueuedVerifier" type="xtce:QueuedVerifierType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">A verifer that means the command is scheduled for execution by the destination.</documentation>
    </annotation>
    </element>
    <element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A verifier that indicates that the command is being executed. An optional Element indicates how far along the command has progressed either as a fixed value or an (possibly scaled) ParameterInstance value.</documentation>
    </annotation>
    </element>
    <element name="CompleteVerifier" type="xtce:CompleteVerifierType" minOccurs="0" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A possible set of verifiers that all must be true for the command be considered completed. Consider that some may not participate due to argument value restriction, if that element is used.</documentation>
    </annotation>
    </element>
    <element name="FailedVerifier" type="xtce:FailedVerifierType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">When true, indicates that the command failed. timeToWait is how long to wait for the FailedVerifier to test true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

ParameterToSet/Derivation is set to abstract and should not be

  • Key: XTCE13-135
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    ParameterToSet/Derivation is a MathOperationType which is abstract. Which means you cannot make an instance of it.

    A simple fix is to make a DerivationType extending MathOperationType.

  • Reported: XTCE 1.2 — Wed, 21 Jun 2023 19:32 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    Reballot: This was resolved when working XTCE13-125

    The resolution XTCE13-166 for XTCE13-125 adds a new type to support specifying arguments inside the "Derivation" element in "ParameterToSetType". This new type, named "ArgumentMathOperationType" is no longer abstract. This effectively moots this issue, so they could be considered to be merged now.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

BinaryEncoding Extension of SequenceContainer Requires SizeInBits Element

  • Key: XTCE13-162
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Within the SequenceContainer element, there is a child element of BinaryEncoding that optionally provides some additional information to use for processing the SequenceContainer content. The BinaryEncoding element requires specifying the SizeInBits element, when that element is not always needed. Being required also presents a problem when using the ErrorDetectCorrect element in a non-deterministic length container.

  • Reported: XTCE 1.2 — Fri, 19 Jul 2024 01:58 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Reballot: Make SizeInBits Optional in ContainerBinaryDataEncodingType

    The "ContainerBinaryDataEncodingType" contains a number of optional additional pieces of metadata about the binary sequence that a container represents. This type is the content of the BinaryEncoding element inside of a CommandContainer or a SequenceContainer element.

    Each of the child elements is optional except for the SizeInBits, which can present as a problem to be mandatory when the ErrorDetectCorrect is used on an abstract base container for which the length is not yet known because a complete container hasn't been defined at that level.

    Propose to make the element optional.

    Existing type definition:

    <complexType name="ContainerBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe container 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>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes the optional inclusion of an error detection and/or correction algorithm used with this container.</documentation>
    </annotation>
    </element>
    <element name="SizeInBits" type="xtce:PositiveLongType">
    <annotation>
    <documentation xml:lang="en">Number of bits this container occupies on the stream being encoded/decoded. This is only needed to "force" the bit length of the container to be a fixed value. In most cases, the entry list would define the size of the container.</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>
    </complexType>

    Revised definition with the minOccurs="0" applied to the SizeInBits element line:

    <complexType name="ContainerBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe container 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>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes the optional inclusion of an error detection and/or correction algorithm used with this container.</documentation>
    </annotation>
    </element>
    <element name="SizeInBits" type="xtce:PositiveLongType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Number of bits this container occupies on the stream being encoded/decoded. This is only needed to "force" the bit length of the container to be a fixed value. In most cases, the entry list would define the size of the container.</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>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

String Encoding Length descriptions needs further clean up

  • Key: XTCE13-30
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The current schema improves upon XTCE 1.1 but still has issues. Firstly it lacks overall clarity and simple syntax. Second it appears to give 2 ways to describe an overall "string box" and dynamic part which may be confusing to some (we should favor one over the other). See for example Fixed plus one of the TerminatingChar or LeadingSize, or Variable/DynamicValue and maxSizeInBits. Also maxSizeInBits is required and this may be a problem in some scenarios. Finally the choice of syntactic element does make it possible to say that variable length has a dynamic look up terminatingChar and LeadingSize.

    The overall use cases of support are:

    • fixed string
    • fixed box, variable string
    • variable string but overall max size (simlar to above)
    • variable string unlimited

    Here's a longer write up:

    1) Fixed string, like as in literally:

    StringDataEncoding/SizeInBits/Fixed/FixedValue

    2) Fixed string BOX but variable inside that...

    StringDataEncoding/SizeInBits/Fixed/FixedValue AND one of Fixed/LeadingSize or Fixed/TerminatingChar

    3) Fixed string BOX but variable inside that... yeah we can say this two ways then:

    StringDataEncoding/Variable/@maxSizeInBits=sizeOf(StringBox) AND one of DynamicValue or DiscreteValue to look up the length from it, and then optionally either LeadingSize or TerminationChar or both even too

    This one is terribly confusing...

    4) Variable and Max size

    StringDataEncoding/Variable/Dynamic|Discrete plus required maxSizeInBits and then optionally either LeadingSize or TerminationChar too

    5) Variable but no max size stated in source material

    StringDataEncoding/Variable/Dynamic|Discrete set maxSizeInBits to ginormous and probably just ignore and then optionally either LeadingSize or TerminationChar too

    So #1 and #2 make sense but are a tad unwieldy syntax wise... well we are probably a little stuck there in regard to "backwards compatibility". This is probably the most used, these two.

    I think #4 makes sense – although mixing in the leading size or termination char seems either just plain confusing or weird...

    #5 is unfortunate but making @maxSizeinBits optional seems quick fix OR the workaround isn't necessarily bad.

    The "let's set everything" #3 isn't great but could be factored away in documentation

  • Reported: XTCE 1.2 — Mon, 14 May 2018 17:31 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Close

    Close in light of work being done in XTCE13-127

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Data encodings: FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm SizeInBits should be optional

  • Key: XTCE13-128
  • Status: closed  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    In data encoding definitions (currently only BinaryDataEncoding but see my other issue XTCE13-124), XTCE should allow the algorithm used in ToBinaryTransformAlgorithm and FromBinaryTransformAlgorithm to determine the size of the data on the wire.

    Thus the SizeInBits which is currently mandatory should be made optional when an algorithm is used.

  • Reported: XTCE 1.2 — Mon, 3 May 2021 14:17 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    Reballot: This was resolved when working XTCE13-162

    It turns out that the issue reported by Nicolae here was not well understood, but that did not matter, because the mandatory nature of the "SizeInBits" element under "BinaryEncoding" created more than one problem. The mandatory nature of the element is removed under the resolution XTCE13-164. That also resolves the problem described here.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

BaseConditionsType too broad

  • Key: XTCE13-114
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Our for a list<element> in the BooleanExpression which made a base type called – BaseConditionsType is a little too broad because it include sub-type now only relevant on the command side.

    we should probably have a ArgumentBaseConditionsType.

    The children of it now are:

    ANDedConditionsType
    ArgumentANDedConditionsType
    ORedConditionsType
    ArgumentORedConditionsType
    ComparisonCheckType
    ArgumentComparisonCheckType

  • Reported: XTCE 1.2 — Fri, 10 Jul 2020 17:33 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Reballot: Split the Base Type to Two Variations for Conditions and Comparison

    A single empty type BaseConditionsType is applied to two separate forms of context value expression checks. These are the Condition types and the Comparison types used within BooleanExpressionType constructs.

    Propose to separate the base type definition in the schema such that those two different semantics have a different empty base type to help prevent them from being interchanged in code after generation from the schema. This resolution does not affect the XML document structure for the XTCE encapsulated data itself, rather merely the way the schema is organized.

    The concept of having the telemetry and commanding variants of these in the inheritance does not appear to provide an issue with the Liskov Substitution Principle, unless something more educated points it out to me.

    First, it would be needed to add a new "BaseComparisonType" above the existing "BaseConditionsType". Only one code block is shown to illustrate context for the entirely new type. The existing type is unchanged:

    <complexType name="BaseComparisonType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base type for comparison related elements that improves the mapping produced by data binding tools.</documentation>
    </annotation>
    </complexType>
    <complexType name="BaseConditionsType" abstract="true">
    <annotation>
    <documentation xml:lang="en">A base type for boolean expression related elements that improves the mapping produced by data binding tools.</documentation>
    </annotation>
    </complexType>

    Then in two of the inherited types, we change the extension from BaseConditionsType to BaseComparisonType. Old and new provided, although the change is just the one line.

    For ComparisonCheckType, existing:

    <complexType name="ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Describe the comparison between the instance (value) of a parameter against either a specified value or another parameter instance.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <sequence>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side parameter instance.</documentation>
    </annotation>
    </element>
    <element name="ComparisonOperator" type="xtce:ComparisonOperatorsType">
    <annotation>
    <documentation xml:lang="en">Comparison operator.</documentation>
    </annotation>
    </element>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side parameter instance. Parameter is assumed to be of the same type as the comparison Parameter.</documentation>
    </annotation>
    </element>
    <element name="Value" type="string">
    <annotation>
    <documentation xml:lang="en">Right hand side value. Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Updated ComparisonCheckType:

    <complexType name="ComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Describe the comparison between the instance (value) of a parameter against either a specified value or another parameter instance.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseComparisonType">
    <sequence>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side parameter instance.</documentation>
    </annotation>
    </element>
    <element name="ComparisonOperator" type="xtce:ComparisonOperatorsType">
    <annotation>
    <documentation xml:lang="en">Comparison operator.</documentation>
    </annotation>
    </element>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side parameter instance. Parameter is assumed to be of the same type as the comparison Parameter.</documentation>
    </annotation>
    </element>
    <element name="Value" type="string">
    <annotation>
    <documentation xml:lang="en">Right hand side value. Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    For ArgumentComparisonCheckType, existing:

    <complexType name="ArgumentComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Identical to ComparisonCheckType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseConditionsType">
    <sequence>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side parameter instance.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side argument instance.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="ComparisonOperator" type="xtce:ComparisonOperatorsType">
    <annotation>
    <documentation xml:lang="en">Comparison operator.</documentation>
    </annotation>
    </element>
    <choice>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side parameter instance. Parameter is assumed to be of the same type as the comparison Argument or Parameter.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side argument instance. Argument is assumed to be of the same type as the comparison Argument or Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="Value" type="string">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Updated ArgumentComparisonCheckType:

    <complexType name="ArgumentComparisonCheckType">
    <annotation>
    <documentation xml:lang="en">Identical to ComparisonCheckType but supports argument instance references.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseComparisonType">
    <sequence>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side parameter instance.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Left hand side argument instance.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="ComparisonOperator" type="xtce:ComparisonOperatorsType">
    <annotation>
    <documentation xml:lang="en">Comparison operator.</documentation>
    </annotation>
    </element>
    <choice>
    <choice>
    <element name="ParameterInstanceRef" type="xtce:ParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side parameter instance. Parameter is assumed to be of the same type as the comparison Argument or Parameter.</documentation>
    </annotation>
    </element>
    <element name="ArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Right hand side argument instance. Argument is assumed to be of the same type as the comparison Argument or Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    <element name="Value" type="string">
    <annotation>
    <documentation xml:lang="en">Specify as: integer data type using xs:integer, float data type using xs:double, string data type using xs:string, boolean data type using xs:boolean, binary data type using xs:hexBinary, enum data type using label name, relative time data type using xs:duration, absolute time data type using xs:dateTime. Values must not exceed the characteristics for the data type or this is a validation error. Takes precedence over an initial value given in the data type. Values are calibrated unless there is an option to override it.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Simplify/align alarm severities across OMG specifications

  • Key: XTCE13-142
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    To align with other specifications within the OMG and AstroUXDS guidance, deprecate the watch and severe alarm severity levels.

  • Reported: XTCE 1.2 — Wed, 20 Mar 2024 20:36 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Deprecated Down to 4 Alarm Concern Levels

    This resolution follows up with the June 2024 technical meeting agreements. The number of concern levels will decrease to 4 in a later XTCE specification, but at present we retain backwards compatibility. We express our intentions in the annotation for the end users.

    Note that the deprecated is introduced inside the enumerations as Ithe author has observed that to be done in other contexts.

    Previous ConcernLevelsType:

    <simpleType name="ConcernLevelsType">
    <annotation>
    <documentation xml:lang="en">Defines six levels: Normal, Watch, Warning, Distress, Critical and Severe, in that order of concern from least to most. These level definitions are used throughout the alarm definitions. An implementation should interpret these as best to match their uniqueness and provide documentation on how this standard maps to their implementation. Not all are likely to be provided, with some either ignored, promoted or demoted to others, or warned on input. There exist some reasonable usage recommendations in the user community.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="normal"/>
    <enumeration value="watch"/>
    <enumeration value="warning"/>
    <enumeration value="distress"/>
    <enumeration value="critical"/>
    <enumeration value="severe"/>
    </restriction>
    </simpleType>

    Proposed ConcernLevelsType:

    <simpleType name="ConcernLevelsType">
    <annotation>
    <documentation xml:lang="en">Defines six levels: Normal, Watch, Warning, Distress, Critical and Severe, in that order of concern from least to most. These level definitions are used throughout the alarm definitions. An implementation should interpret these as best to match their uniqueness and provide documentation on how this standard maps to their implementation. Not all are likely to be provided, with some either ignored, promoted or demoted to others, or warned on input. There exist some reasonable usage recommendations in the user community.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="normal">
    <annotation>
    <documentation xml:lang="en">The case of "normal" or "no concern level" is generally the default. This value can be useful when describing an exception or disabling when the more typical case is a non-normal concern level.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="watch">
    <annotation>
    <documentation xml:lang="en">DEPRECATED: The lowest level of concern. Systems that support only 3 or 4 concern levels have been observed to promote "watch" to "warning" during data processing, if this enumeration is not explicitly supported. This value may not exist in future versions of this specification.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="warning">
    <annotation>
    <documentation xml:lang="en">A level of concern to be interpreted by the user as less than the highest possible concern. This is intended by the specification to be quite vague. The project operational concept will explicitly define how these are to be used.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="distress">
    <annotation>
    <documentation xml:lang="en">A level of concern to be interpreted by the user as greater than the least concern but not yet rising to the highest possible concern. This is intended by the specification to be quite vague. The project operational concept will explicitly define how these are to be used.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="critical">
    <annotation>
    <documentation xml:lang="en">A level of concern to be interpreted by the user as the highest possible concern. This is intended by the specification to be quite vague. The project operational concept will explicitly define how these are to be used.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="severe">
    <annotation>
    <documentation xml:lang="en">DEPRECATED: The highest level of concern. Systems that support only 3 or 4 concern levels have been observed to demote "severe" to "critical" during data processing, if this enumeration is not explicitly supported. This value may not exist in future versions of this specification.</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

clarify semantics of context cals (possibly same as context alarms)

  • Key: XTCE13-145
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Clarify that the list of contexts is in a specific ordering, and that as it stands now the <xsd:sequence> is in an order and that's the ordering. Or, consider adding a required "ordering" attribute to enforce the order. Or perhaps that subtly changes the semantics and we don't want to do any of it in which case we might say that...

  • Reported: XTCE 1.2 — Wed, 24 Apr 2024 15:59 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Add additional ContextCalibrator annotation

    The ContextCalibratorListType alludes to the desired behavior, but that definition does not appear on the elements themselves in the FloatDataEncodingType and IntegerDataEncodingType definitions.

    Propose to update the annotation on these.

    Existing FloatDataEncodingType:

    <complexType name="FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For common encodings of floating point data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when no Context Calibrators are provided or evaluate to true, based on their MatchCriteria.</documentation>
    </annotation>
    </element>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when a MatchCriteria evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="encoding" type="xtce:FloatEncodingType" default="IEEE754_1985">
    <annotation>
    <documentation xml:lang="en">Specifies real/decimal numeric value to raw encoding method, with the default being "IEEE754_1985".</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatEncodingSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Number of bits to use for the float raw encoding method, with 32 being the default. Not every number of bits is valid for each encoding method.</documentation>
    <appinfo>Verify the number of bits for encoding is valid for the encoding method.</appinfo>
    </annotation>
    </attribute>
    <attribute name="changeThreshold" type="double" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    New FloatDataEncodingType (note only 1 sentence change in the documentation):

    <complexType name="FloatDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For common encodings of floating point data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when no Context Calibrators are provided or evaluate to true, based on their MatchCriteria.</documentation>
    </annotation>
    </element>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when a MatchCriteria evaluates to true. The first in the list to match takes precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="encoding" type="xtce:FloatEncodingType" default="IEEE754_1985">
    <annotation>
    <documentation xml:lang="en">Specifies real/decimal numeric value to raw encoding method, with the default being "IEEE754_1985".</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:FloatEncodingSizeInBitsType" default="32">
    <annotation>
    <documentation xml:lang="en">Number of bits to use for the float raw encoding method, with 32 being the default. Not every number of bits is valid for each encoding method.</documentation>
    <appinfo>Verify the number of bits for encoding is valid for the encoding method.</appinfo>
    </annotation>
    </attribute>
    <attribute name="changeThreshold" type="double" use="optional">
    <annotation>
    <documentation>A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Existing IntegerDataEncodingType:

    <complexType name="IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For all major encodings of integer data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when no Context Calibrators are provided or evaluate to true, based on their MatchCriteria.</documentation>
    </annotation>
    </element>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when a MatchCriteria evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="encoding" type="xtce:IntegerEncodingType" default="unsigned">
    <annotation>
    <documentation xml:lang="en">Specifies integer numeric value to raw encoding method, with the default being "unsigned".</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="8">
    <annotation>
    <documentation xml:lang="en">Number of bits to use for the raw encoding, with 8 being the default.</documentation>
    </annotation>
    </attribute>
    <attribute name="changeThreshold" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation xml:lang="en">A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements, such as for an analog-to-digital converter that dithers in the least significant bit. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    New IntegerDataEncodingType (note only 1 sentence change in the documentation):

    <complexType name="IntegerDataEncodingType">
    <annotation>
    <documentation xml:lang="en">For all major encodings of integer data</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:DataEncodingType">
    <sequence>
    <element name="DefaultCalibrator" type="xtce:CalibratorType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when no Context Calibrators are provided or evaluate to true, based on their MatchCriteria.</documentation>
    </annotation>
    </element>
    <element name="ContextCalibratorList" type="xtce:ContextCalibratorListType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Calibrator to be applied to the raw uncalibrated value to arrive at the engineering/calibrated value when a MatchCriteria evaluates to true. The first in the list to match takes precedence.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="encoding" type="xtce:IntegerEncodingType" default="unsigned">
    <annotation>
    <documentation xml:lang="en">Specifies integer numeric value to raw encoding method, with the default being "unsigned".</documentation>
    </annotation>
    </attribute>
    <attribute name="sizeInBits" type="xtce:PositiveLongType" default="8">
    <annotation>
    <documentation xml:lang="en">Number of bits to use for the raw encoding, with 8 being the default.</documentation>
    </annotation>
    </attribute>
    <attribute name="changeThreshold" type="xtce:NonNegativeLongType" use="optional">
    <annotation>
    <documentation xml:lang="en">A changeThreshold may optionally be specified to inform systems of the minimum change in value that is significant. This is used by some systems to limit the telemetry processing and/or recording requirements, such as for an analog-to-digital converter that dithers in the least significant bit. If the value is unspecified or zero, any change is significant.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Clarify RepeatEntry's values and what they mean

  • Key: XTCE13-143
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Firstly because repeat is optional, it seems intuitive that this is the same as repeat=0. And that intuitively means the entry repeats 0 times, which means it appears 1 time in the container entry list. Likewise a repeat=1, means the entry appears 2 times and forth. This to me makes sense but maybe it doesn't.
    The syntax right now is broad and would allow all sort of values including negative ones. It's not clear that that would be anything but an error.
    Given all that we should say something about this in the annotation at the very least. And since FixedValue is a long we could change it to positive-only or perhaps non-negative. The DiscreteLookup value's type could also be modified (we'd have to make a "PositveOnlyDiscreteLookup" or some such). The last is a DynamicLookup and that would have to be enforced outside the syntax, we could imply it by calling it "PositiveOnlyDynamicLookup" or similar.
    Finally add annotation.

  • Reported: XTCE 1.2 — Wed, 17 Apr 2024 18:43 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Improve Annotation on RepeatEntry Elements

    The RepeatEntryType annotations are not useful. Propose to make these more specific.

    Existing RepeatType:

    <complexType name="RepeatType">
    <annotation>
    <documentation xml:lang="en">Hold a structure that can be repeated X times, where X is the Count</documentation>
    </annotation>
    <sequence>
    <element name="Count" type="xtce:IntegerValueType">
    <annotation>
    <documentation xml:lang="en">Value (either fixed or dynamic) that contains the count of repeated structures.</documentation>
    </annotation>
    </element>
    <element name="Offset" type="xtce:IntegerValueType" minOccurs="0"/>
    </sequence>
    </complexType>

    New RepeatType:

    <complexType name="RepeatType">
    <annotation>
    <documentation xml:lang="en">Contains elements that describe how an Entry is identically repeated. This includes a Count of the number of appearances and an optional Offset in bits that may occur between appearances. A Count of 1 indicates no repetition. The Offset default is 0 when not specified.</documentation>
    </annotation>
    <sequence>
    <element name="Count" type="xtce:IntegerValueType">
    <annotation>
    <documentation xml:lang="en">Value (either fixed or dynamic) that contains the count of appearances for an Entry. The value must be positive where 1 is the same as not specifying a RepeatEntry element at all.</documentation>
    </annotation>
    </element>
    <element name="Offset" type="xtce:IntegerValueType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Value (either fixed or dynamic) that contains an optional offset in bits between repeats of the Entry. The default is 0, which is contiguous. The value must be 0 or positive. Empty offset after the last repeat count is not implicitly reserved, so the parent EntryList should consider if these are occupied bits when placing the next Entry.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Clarify Behavior of Context Alarms Only Containing a Match

  • Key: XTCE13-139
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    It is unclear in the documentation how it should be handled when a parameter defines a context alarm for which only a match element is provided. This is valid in the schema.

  • Reported: XTCE 1.2 — Thu, 7 Dec 2023 16:20 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Add additional ContextMatch annotations

    To make this scenario more clear to the users, we propose to add the following additional annotation.

    Existing ContextMatchType:

    <complexType name="ContextMatchType">
    <annotation>
    <documentation xml:lang="en">A MatchCriteriaType used for Context selection.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType"/>
    </complexContent>
    </complexType>

    New ContextMatchType:

    <complexType name="ContextMatchType">
    <annotation>
    <documentation xml:lang="en">A MatchCriteriaType used for Context selection. It is possible that no match evaluates to true, which results in the default element being used. It is also possible that a match can have an empty context change, in which case the default is replaced with nothing.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:MatchCriteriaType"/>
    </complexContent>
    </complexType>

    Existing BinaryContextAlarmListType:

    <complexType name="BinaryContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context binary alarms, duplicates are valid. Process the contexts in list order. See BinaryContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:BinaryContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    New BinaryContextAlarmListType:

    <complexType name="BinaryContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context binary alarms, duplicates are valid. Process the contexts in list order. See BinaryContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:BinaryContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a new alarm definition and a context match. The match takes precedence over any default alarm when the first in the overall list evaluates to true. It is also possible the alarm definition is empty, in which case the context means no alarm defined when the match is true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Existing BooleanContextAlarmListType:

    <complexType name="BooleanContextAlarmListType">
    <sequence>
    <element name="ContextAlarm" type="xtce:BooleanContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    New BooleanContextAlarmListType:

    <complexType name="BooleanContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context boolean alarms, duplicates are valid. Process the contexts in list order. See BooleanContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:BooleanContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a new alarm definition and a context match. The match takes precedence over any default alarm when the first in the overall list evaluates to true. It is also possible the alarm definition is empty, in which case the context means no alarm defined when the match is true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Existing EnumerationContextAlarmListType:

    <complexType name="EnumerationContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context enumeration alarms, duplicates are valid. Process the contexts in list order. See EnumerationContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:EnumerationContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe the alarm matching context criteria and the alarm definition itself.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    New EnumerationContextAlarmListType:

    <complexType name="EnumerationContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context enumeration alarms, duplicates are valid. Process the contexts in list order. See EnumerationContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:EnumerationContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a new alarm definition and a context match. The match takes precedence over any default alarm when the first in the overall list evaluates to true. It is also possible the alarm definition is empty, in which case the context means no alarm defined when the match is true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Existing StringContextAlarmListType:

    <complexType name="StringContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">An ordered collection of numeric alarms associated with a context. Process the contexts in list order. See StringContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:StringContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    New StringContextAlarmListType:

    <complexType name="StringContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered collection of context string alarms, duplicates are valid. Process the contexts in list order. See StringContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:StringContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a new alarm definition and a context match. The match takes precedence over any default alarm when the first in the overall list evaluates to true. It is also possible the alarm definition is empty, in which case the context means no alarm defined when the match is true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Existing NumericContextAlarmListType:

    <complexType name="NumericContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">An ordered collection of numeric alarms associated with a context. A context is an alarm definition on a parameter which is valid only in the case of a test on the value of other parameters. Process the contexts in list order. Used by both FloatParameterType and IntegerParameterType. See NumericContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:NumericContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A contextual alarm definition for the parameter that uses this type that is valid when a test against the value of one or more other parameters evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    New NumericContextAlarmListType:

    <complexType name="NumericContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">An ordered collection of numeric alarms associated with a context. A context is an alarm definition on a parameter which is valid only in the case of a test on the value of other parameters. Process the contexts in list order. Used by both FloatParameterType and IntegerParameterType. See NumericContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:NumericContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a new alarm definition and a context match. The match takes precedence over any default alarm when the first in the overall list evaluates to true. It is also possible the alarm definition is empty, in which case the context means no alarm defined when the match is true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Existing TimeContextAlarmListType:

    <complexType name="TimeContextAlarmListType">
    <sequence>
    <element name="ContextAlarm" type="xtce:TimeContextAlarmType" maxOccurs="unbounded"/>
    </sequence>
    </complexType>

    New TimeContextAlarmListType:

    <complexType name="TimeContextAlarmListType">
    <annotation>
    <documentation xml:lang="en">An ordered collection of temporal alarms associated with a context. A context is an alarm definition on a parameter which is valid only in the case of a test on the value of other parameters. Process the contexts in list order. See TimeContextAlarmType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextAlarm" type="xtce:TimeContextAlarmType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a new alarm definition and a context match. The match takes precedence over any default alarm when the first in the overall list evaluates to true. It is also possible the alarm definition is empty, in which case the context means no alarm defined when the match is true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Existing ContextSignificanceListType:

    <complexType name="ContextSignificanceListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered list of ContextSignificance elements where the significance on the first context match to test true is used as the significance of the MetaCommand. If there is a DefaultSignificance, it is overrideen by the matching context. See ContextSignificantType and MetaCommandType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextSignificance" type="xtce:ContextSignificanceType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a significance level for a MetaCommand definition where the significance level depends on matching a context value. See ContextMatchType and SignificanceType.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    New ContextSignificanceListType:

    <complexType name="ContextSignificanceListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered list of ContextSignificance elements where the significance on the first context match to test true is used as the significance of the MetaCommand. If there is a DefaultSignificance, it is overrideen by the matching context. See ContextSignificantType and MetaCommandType.</documentation>
    </annotation>
    <sequence>
    <element name="ContextSignificance" type="xtce:ContextSignificanceType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">A Context contains a different significance definition and a context match. The match takes precedence over any default significance when the first in the overall list evaluates to true.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Reconsider if Specific Color Names Should be Referenced

  • Key: XTCE13-140
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Given that alarm consequence/significance labels are concepts and colors are implementations, should the XTCE schema refer to the colors by name? Perhaps it should refer to implementation of suggest AstroUX as a reference?

  • Reported: XTCE 1.2 — Thu, 7 Dec 2023 21:23 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Remove implementation specific color names from the schema

    It is not good practice to dictate implementation in the XTCE schema. We will remove the reference to specific color names for displays by updating the documentation and throwing a hat tip our to AstroUX for generally managing a standard for this.

    Existing ConcernLevelsType:

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

    New ConcernLevelsType:

    <simpleType name="ConcernLevelsType">
    <annotation>
    <documentation xml:lang="en">Defines six levels: Normal, Watch, Warning, Distress, Critical and Severe, in that order of concern from least to most. These level definitions are used throughout the alarm definitions. An implementation should interpret these as best to match their uniqueness and provide documentation on how this standard maps to their implementation. Not all are likely to be provided, with some either ignored, promoted or demoted to others, or warned on input. There exist some reasonable usage recommendations in the user community.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="normal"/>
    <enumeration value="watch"/>
    <enumeration value="warning"/>
    <enumeration value="distress"/>
    <enumeration value="critical"/>
    <enumeration value="severe"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

ArgumentType References Mixed with ParameterTypes in Key

  • Key: XTCE13-155
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The name constraint for ArgumentType elements enforces uniqueness with ParameterType elements that appear in the CommandMetaData.

    <key name="argumentTypeNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique argument type name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:ArgumentTypeSet/|xtce:CommandMetaData/xtce:ParameterTypeSet/"/>
    <field xpath="@name"/>
    </key>

    This does not make sense because "argumentTypeRef" is distinct from "parameterTypeRef" in all cases.

  • Reported: XTCE 1.2 — Sun, 2 Jun 2024 20:05 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Release Argument and Parameter Type Name Uniqueness

    Proposal is to release the uniqueness key from binding CommandMetaData/ParameterTypeSet names with CommandMetaData/ArgumentTypeSet names.

    Existing key definition:

    <key name="argumentTypeNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique argument type name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:ArgumentTypeSet/|xtce:CommandMetaData/xtce:ParameterTypeSet/"/>
    <field xpath="@name"/>
    </key>

    Revised key definition:

    <key name="argumentTypeNameKey">
    <annotation>
    <documentation xml:lang="en">This key ensures a unique argument type name at the system level.</documentation>
    </annotation>
    <selector xpath="xtce:CommandMetaData/xtce:ArgumentTypeSet/*"/>
    <field xpath="@name"/>
    </key>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Non-ASCII characters in XSD annotations cause tooling issues

  • Key: XTCE13-129
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Remove use of non-ASCII characters to improve tooling ease of use. These characters are utilized within Annotation fields.

    Symbols to change:

    ’ '


    Also, in ArgumentAssignmentListType, add a single quote before "power on"

  • Reported: XTCE 1.2 — Tue, 15 Jun 2021 18:11 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Address the non-ASCII characters

    The description of this resolution is a little different than the rest in that the author did a scan of the document that returned fragments of text containing non-ASCII characters. These were converted to ASCII equivalents except in minor changes otherwise annotated below.

    Tool link: https://pages.cs.wisc.edu/~markm/ascii.html

    List of findings:

    Character #19599 ned in the parameter’s type definition),
    changed to regular apostrophe

    Character #29797 mentation dependent – these should be fl
    changed to regular minus sign

    Character #30075 mentation dependent – these should be fl
    changed to regular minus sign

    Character #30187 the previous entry – zero (0) is the de
    changed to regular minus sign

    Character #33494 The parent container’s entries are place
    changed to regular apostrophe

    Character #35288 s. Describe an entry’s location in the c
    changed to regular apostrophe

    Character #35564 ntryType). The entry’s IncludeCondition
    changed to regular apostrophe

    Character #48455 under this data type’s name. The Member
    changed to regular apostrophe

    Character #48510 data block and block’s size is defined b
    changed to regular apostrophe

    Character #48564 dings of each Member’s type reference. T
    changed to regular apostrophe

    Character #48805 is of a member of P’s aggregate type.
    changed to regular apostrophe

    Character #49828 (sometimes called a “blob type”). It may
    changed to regular double quotes (both)

    Character #51112 as two values only: ‘True’ (1) or ‘False’ (0)
    changed to regular double quotes (all 4) instead of UTF single quotes

    Character #63383 meter properties to ‘local’ but the synt
    changed to regular double quotes (all 4) instead of UTF single quotes

    Character #68412 arameter. Uses Unix ‘like’ naming across
    changed to Unix-like without the single quotes

    Character #79968 under this data type’s name. The Member
    changed to regular apostrophe

    Character #80023 data block and block’s size is defined b
    changed to regular apostrophe

    Character #80077 dings of each Member’s type reference. T
    changed to regular apostrophe

    Character #80318 is of a member of P’s aggregate type.
    changed to regular apostrophe

    Character #80871 Command. Use it to ‘narrow’ a MetaComma
    changed to regular double quotes (both)

    Character #81012 rrowed to a power on’ command by assigni
    put the words "power on" in double quotes, removing the dangling single quote

    Character #81063 e of an argument to ‘on’. See ArgumentA
    changed to regular double quotes (both)

    Character #101938 her MetaCommand. It’s required Argument
    changed to regular apostrophe

    Character #102994 type (often called “blob type”). The bi
    changed to regular double quotes (both)

    Character #104209 as two values only: ‘True’ (1) or ‘False
    changed to regular double quotes (all 4) instead of UTF single quotes

    Character #117234 ners. A MetaCommand’s CommandContainer
    changed to regular apostrophe

    Character #136922 ere may be multiple ‘complete’ and 'execution' ve
    changed to regular double quotes for both pairs of these in this documentation element.

    Character #173375 under this data type’s name. The Member
    changed to regular apostrophe

    Character #173430 data block and block’s size is defined b
    changed to regular apostrophe

    Character #173484 dings of each Member’s type reference. T
    changed to regular apostrophe

    Character #173725 is of a member of P’s aggregate type.
    changed to regular apostrophe

    Character #183404 type (often called “blob type”). The bi
    changed to regular double quotes (both)

    Character #185349 as two values only: ‘True’ (1) or ‘False
    changed to regular double quotes (all 4) instead of UTF single quotes

    Character #252438 x0C), 0 (0x0D) with ‘3’ being first in t
    removed both single quotes to be consistent with remaining text

    Character #252562 x0B), 3 (0x0A) with ‘0’ being first in t
    removed both single quotes to be consistent with remaining text

    Character #282862 for the path: '/', ‘..’ and ‘.’ (multiple consecutive ‘/’s are treated as
    changed to regular apostrophe each of 4 instance pairs here

    Character #283533 o point to no item (“a dangling name reference”).
    changed to regular double quotes (both)

    Character #308743 larm (minViolations – the counts to go o
    changed to regular minus sign

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Change Alarm Element Bad Attributes

  • Key: XTCE13-138
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Not sure that specifying range form in a change alarm makes sense as the min/max are relative to the value itself. In addition, both exclusive and inclusive range values are allowed and that doesn't seem to make sense for exclusive.

  • Reported: XTCE 1.2 — Wed, 6 Dec 2023 18:28 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    Combined with Range Form Updates

    This concern is overcome by events in that the Range Form annotation changes address this.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

rangeForm annotation needs work

  • Key: XTCE13-73
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The rangeForm annotation is vague and needs improvement. There are two places it occurs – one at the attribute level with another brief mention at the schema type:
    "A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch. The most common form used is "outside" and is the default."

    The key problem is the term "inverts" is not really defined and so the entire explanation is overly general.

  • Reported: XTCE 1.2 — Thu, 3 Oct 2019 14:35 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    rangeform annotation updates in several locations

    Improve the documentation embedded in the schema that describes RangeFormType, MultiRangeType, and AlarmMultiRangesType while taking into account the attributes that leverage these types.

    The original definition of RangeFormType:

    <simpleType name="RangeFormType">
    <annotation>
    <documentation>Defines whether the defined range between the minimum and maximum is the outside or inside the range being defined. The default, outside matches values less than the minimum and greater than the maximum. Inside matches values between the minimum and maximum.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="outside"/>
    <enumeration value="inside"/>
    </restriction>
    </simpleType>

    Replace the original definition with this new RangeFormType:

    <simpleType name="RangeFormType">
    <annotation>
    <documentation xml:lang="en">Defines inside and outside enumerated terms, where the term outside means the range is (-inf, minimum) and (maximum, inf) – that is a range where acceptable values must be less than the minimum and greater than the maximum, and the term inside means the range is (minimum, maximum) – that is acceptable values are between the minimum and maximum (either the min or max may be inclusive or exclusive).</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="outside"/>
    <enumeration value="inside"/>
    </restriction>
    </simpleType>

    There is a rangeForm attribute that leverages the RangeFormType in the AlarmRangesType. This is the original definition of that attribute:

    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation xml:lang="en">A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch. The most common form used is "outside" and is the default.</documentation>
    </annotation>
    </attribute>

    Replace that attribute definition with the following modified one:

    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation xml:lang="en">A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. This means each min, max pair are a range: (-inf, min) or (-inf, min], and [max, inf) or (max, inf). However a value of inside "inverts" these bands: -normal -watch -warning -distress -critical severe +critical +distress +warning +watch, +normal. This means each min, max pair form a range of (min, max) or [min, max) or (min, max] or [min, max]. The most common form used is "outside" and it is the default. The set notation used defines parenthesis as exclusive and square brackets as inclusive.</documentation>
    </annotation>
    </attribute>

    The original definition of MultiRangeType:

    <complexType name="MultiRangeType">
    <annotation>
    <documentation xml:lang="en">The alarm multi-range element type permits users to define multiple alarm ranges in a sequence that goes beyond the more typical "inside" and "outside" range definitions. It can be thought of as a "barber pole" definition.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation xml:lang="en">A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. A value of inside "inverts" these bands: -green -watch -warning -distress -critical severe +critical +distress +warning +watch. The most common form used is "outside" and is the default.</documentation>
    </annotation>
    </attribute>
    <attribute name="level" type="xtce:ConcernLevelsType">
    <annotation>
    <documentation xml:lang="en">The level of concern for this alarm definition.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Replace the original definition with this new MultiRangeType:

    <complexType name="MultiRangeType">
    <annotation>
    <documentation xml:lang="en">The alarm multi-range element type permits users to define multiple alarm ranges in a sequence that goes beyond the more typical "inside" and "outside" range definitions. It can be thought of as a "barber pole" definition.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:FloatRangeType">
    <attribute name="rangeForm" type="xtce:RangeFormType" default="outside">
    <annotation>
    <documentation xml:lang="en">A value of outside specifies that the most severe range is outside all the other ranges: -severe -critical -distress -warning -watch normal +watch +warning +distress +critical +severe. This means each min, max pair are a range: (-inf, min) or (-inf, min], and [max, inf) or (max, inf). However a value of inside "inverts" these bands: -normal -watch -warning -distress -critical severe +critical +distress +warning +watch, +normal. This means each min, max pair form a range of (min, max) or [min, max) or (min, max] or [min, max]. The most common form used is "outside" and it is the default. The set notation used defines parenthesis as exclusive and square brackets as inclusive.</documentation>
    </annotation>
    </attribute>
    <attribute name="level" type="xtce:ConcernLevelsType">
    <annotation>
    <documentation xml:lang="en">The level of concern for this alarm definition.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    The original definition of AlarmMultiRangesType:

    <complexType name="AlarmMultiRangesType">
    <annotation>
    <documentation xml:lang="en">Describe any number of alarm ranges, each with its own level (normal, warning, watch, distress, critical, severe) and range form. Ranges may overlap, be disjoint and so forth. Ranges within the value sprectrum non-specified are non-normal. The most severe range level of value within the ranges is the level of the alarm. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <element name="Range" type="xtce:MultiRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe any number of alarm ranges, each with its own level (normal, warning, watch, distress, critical, severe) and range form (inside – (min,max),[min,max), (min, max], [min, max], or outside. Ranges may overlap, be disjoint and so forth. Ranges within the value sprectrum non-specified are non-normal. The most severe range level of value within the ranges is the level of the alarm. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Replace the original definition with this new AlarmMultiRangesType:

    <complexType name="AlarmMultiRangesType">
    <annotation>
    <documentation xml:lang="en">Describe any number of alarm ranges, each with its own level (normal, warning, watch, distress, critical, severe) and range form (inside – (min,max), [min,max), (min, max], [min, max], or outside – (-inf, min) or (-inf,min] and [max, +inf) or (max,+inf). Ranges may overlap, be disjoint and so forth. Ranges within the value spectrum non-specified are non-normal. The most severe range level of value within the ranges is the level of the alarm. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:BaseAlarmType">
    <sequence>
    <element name="Range" type="xtce:MultiRangeType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe any number of alarm ranges, each with its own level (normal, warning, watch, distress, critical, severe) and range form (inside – (min,max),[min,max), (min, max], [min, max], or outside – (-inf, min) or (-inf,min] and [max, +inf) or (max,+inf).. Ranges may overlap, be disjoint and so forth. Ranges within the value spectrum non-specified are non-normal. The most severe range level of value within the ranges is the level of the alarm. Range values are in calibrated engineering units. See FloatRangeType.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

RelativeTime's ChangePerSecondRangeAlarm should be a TimeChangesPerSecondAlarmType

  • Key: XTCE13-136
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    RelativeTimeParamaterType static and change alarms are both TimeAlarmRangesType. At the very least it would be clearer if the ChangePerSecondRangeAlarm is its own type.
    A simple solution would be to create a new type (TimeChangePerSecondRangeAlarmType) and have it extend TimeAlarmRangesType.
    (Assuming that it's correct that both of these should describe alarms in the same using same underlying type.)

  • Reported: XTCE 1.2 — Mon, 17 Jul 2023 16:11 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Reuse of TimeAlarmRangesType Not Broken

    The point of the issue here is seen. It is not obvious in the schema types, but re-use of schema elements is by design. The annotation describes how the physics should be interpreted. Propose not to change this.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Possible typo of word "difference" instead of "different"

  • Key: XTCE13-134
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    "There are eight different verifiers each associated with difference states in command processing"

  • Reported: XTCE 1.2 — Wed, 21 Sep 2022 20:59 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Correct the typo until a better verifier description comes along

    Replace the documentation text for the complex type VerifierSetType to correct the spelling error. Note that the change is exactly 1 word.

    The previous definition of this type:

    <complexType name="VerifierSetType">
    <annotation>
    <documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with difference states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple ‘complete’ and 'execution' verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the 'complete' and 'execution' verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>
    </annotation>
    <sequence>
    <element name="TransferredToRangeVerifier" type="xtce:TransferredToRangeVerifierType" minOccurs="0"/>
    <element name="SentFromRangeVerifier" type="xtce:SentFromRangeVerifierType" minOccurs="0"/>
    <element name="ReceivedVerifier" type="xtce:ReceivedVerifierType" minOccurs="0"/>
    <element name="AcceptedVerifier" type="xtce:AcceptedVerifierType" minOccurs="0"/>
    <element name="QueuedVerifier" type="xtce:QueuedVerifierType" minOccurs="0"/>
    <element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded"/>
    <element name="CompleteVerifier" type="xtce:CompleteVerifierType" minOccurs="0" maxOccurs="unbounded"/>
    <element name="FailedVerifier" type="xtce:FailedVerifierType" minOccurs="0"/>
    </sequence>
    </complexType>

    Replace with:

    <complexType name="VerifierSetType">
    <annotation>
    <documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with different states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple ‘complete’ and 'execution' verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the 'complete' and 'execution' verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>
    </annotation>
    <sequence>
    <element name="TransferredToRangeVerifier" type="xtce:TransferredToRangeVerifierType" minOccurs="0"/>
    <element name="SentFromRangeVerifier" type="xtce:SentFromRangeVerifierType" minOccurs="0"/>
    <element name="ReceivedVerifier" type="xtce:ReceivedVerifierType" minOccurs="0"/>
    <element name="AcceptedVerifier" type="xtce:AcceptedVerifierType" minOccurs="0"/>
    <element name="QueuedVerifier" type="xtce:QueuedVerifierType" minOccurs="0"/>
    <element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded"/>
    <element name="CompleteVerifier" type="xtce:CompleteVerifierType" minOccurs="0" maxOccurs="unbounded"/>
    <element name="FailedVerifier" type="xtce:FailedVerifierType" minOccurs="0"/>
    </sequence>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Invalid schema exception with xerces parser

  • Key: XTCE13-130
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    We have experienced the following error with the Xerces XML parser:

    Exception thrown at 0x00007FFB902D4F69 in InstallDB4.exe: Microsoft C++ exception: xercesc_3_0::InvalidDatatypeValueException at memory location 0x000000000014D5A0.

    It seems to be driven by this line:
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0x0"/>

    Changing the default value to "0" seems to make the problem go away.

    Can we change the line instead to:
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0"/>

  • Reported: XTCE 1.2 — Thu, 20 Jan 2022 13:58 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Change idlePattern default value to zero

    This appears to be a schema processing error in Xerces, although that is not proven for sure. The union of types in FixedIntegerValueType appears not to be observed. Of course, troubles with other schema processors have certainly been seen in other areas.

    To be more friendly to the software, we propose to change the idlePattern attribute definition to remove the hexadecimal syntax in the default value instead to:
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0"/>

    The existing complexType element containing the definition above in original context with default="0x0":

    <complexType name="SequenceContainerType">
    <annotation>
    <documentation xml:lang="en">Describes the binary layout/packing of data and also related properties, including an entry list of parameters, parameter segments, array parameters, stream segments, containers, and container segments. Sequence containers may extend other sequence containers (see BaseContainerType). The parent container’s entries are placed before the entries in the child container forming one entry list. An inheritance chain may be formed using this mechanism, but only one entry list is being created. Sequence containers may be marked as "abstract", when this occurs an instance of it cannot itself be created. The idle pattern is part of any unallocated space in the container. See EntryListType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ContainerType">
    <sequence>
    <element name="EntryList" type="xtce:EntryListType">
    <annotation>
    <documentation xml:lang="en">List of item entries to pack/encode into this container definition.</documentation>
    </annotation>
    </element>
    <element name="BaseContainer" type="xtce:BaseContainerType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Optional inheritance for this container from another named container.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="abstract" type="boolean" default="false">
    <annotation>
    <documentation xml:lang="en">Abstract container definitions that are not instantiated, rather only used as bases to inherit from to create specialized container definitions.</documentation>
    </annotation>
    </attribute>
    <attribute name="idlePattern" type="xtce:FixedIntegerValueType" default="0x0">
    <annotation>
    <documentation xml:lang="en">The idle pattern is part of any unallocated space in the container. This is uncommon.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Is rangeForm specialization needed for Change and Multi band alarms?

  • Key: XTCE13-74
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    RangeForm now appears in Static, Change and the multi band. It's not clear these all make sense to me.

    In the static ranges – having the red be the most severe inner band and green "good" on the outside does make sense although I get the impression the use cases are less in number than the standard way folks think of limits. (you're going too fast! not – you're not going fast enough!)

    In the change alarm, which I think of mainly as deltas – again intuitively checking for big changes make sense. Unwanted big jumps are intuitive. But unwanted little jumps? That is big jumps are good? Is there a real use case – perhaps we can jam it into the annotation.

    Finally for the multirange alarm. The rangeForm is at each band. I suspect but don't know that this was to change the range set meaning...
    Intuitively "inside" would be something like this: [min, max] – where x is between them is "ok" ...

    And "outside" would be (-inf, min] and [max, inf) ... that is ranges point 'away'...

    But maybe not – who knows!? Given that though the default is "outside" when perhaps most would want it to be "inside" etc...

    I just wonder if we have done this correctly or its slipped through and is overly general because we inherited the various types, etc...

  • Reported: XTCE 1.2 — Thu, 3 Oct 2019 14:46 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    merge with XTCE13-74 resolution number 88

    By fixing the annotation i believe this is addressed in XTCE 12-73

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Disallow duplicate labels in the EnumerationList

  • Key: XTCE13-115
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The EnumerationList should probably have a key to disallow the duplicate labels. (similar to the @name keys)

  • Reported: XTCE 1.2 — Wed, 15 Jul 2020 17:45 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Duplicated in Enumeration Labels Acceptable

    After discussion at the September RTF, it appears to be the consensus that duplicate labels in an EnumerationList are acceptable and have a valid use case.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Discrete lookup list has no default (or i don't get it)

  • Key: XTCE13-110
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The discrete lookup list, also sprinkled about the syntax tree retrieves the specified numeric value if its condition evaluates to true. for particular discrete in the list. there are several kinds of conditions. The text isn't completely clear but it seems the first discrete lookup in the list that evaluates to true – returns that value. But what happens if none eval to true? it seems that default value is warrented.

    Note: the value is a long. Therefore it does not have same problem as dynamic lookups double data types for integer syntax items.

  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 19:31 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Discrete Lookups Require a "false" Condition Value

    It is not clear what to do with an XTCE DiscreteLookupList element in the event that all the child DiscreteLookup elements never evaluate to "true". As a result, no value can be determined.

    The DiscreteLookupList element should have a "defaultValue" attribute that takes effect when no conditions in the child element evaluate to "true".

    In order to make this happen, both the DiscreteLookupListType and the ArgumentDiscreteLookupListType need to have this new attribute added.

    Original DiscreteLookupListType:

    <complexType name="DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered table of integer values and associated conditions, forming a lookup table. The list may have duplicates. The table is evaluated from first to last, the first condition to be true returns the value associated with it. See DiscreteLookupType.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:DiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Revised DiscreteLookupListType:

    <complexType name="DiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Describe an ordered table of integer values and associated conditions, forming a lookup table. The list may have duplicates. The table is evaluated from first to last, the first condition to be true returns the value associated with it. See DiscreteLookupType.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:DiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="defaultValue" type="long" use="required">
    <annotation>
    <documentation xml:lang="en">In the event that no lookup condition evaluates to true, then this value will be used.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Original ArgumentDiscreteLookupListType:

    <complexType name="ArgumentDiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Identical to DiscreteLookupListType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:ArgumentDiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from arguments and/or parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    </complexType>

    Revised ArgumentDiscreteLookupListType:

    <complexType name="ArgumentDiscreteLookupListType">
    <annotation>
    <documentation xml:lang="en">Identical to DiscreteLookupListType but supports argument instance references.</documentation>
    </annotation>
    <sequence>
    <element name="DiscreteLookup" type="xtce:ArgumentDiscreteLookupType" maxOccurs="unbounded">
    <annotation>
    <documentation xml:lang="en">Describe a lookup condition set using discrete values from arguments and/or parameters.</documentation>
    </annotation>
    </element>
    </sequence>
    <attribute name="defaultValue" type="long" use="required">
    <annotation>
    <documentation xml:lang="en">In the event that no lookup condition evaluates to true, then this value will be used.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Note that the change above is the addition of the "attribute" schema element.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Possible typo of word "encoded" as "endcode"

  • Key: XTCE13-116
  • Status: closed  
  • Source: CACI ( Zebulun Barnett)
  • Summary:

    Appears to be a typo in the BinaryDataEncoding description in the ParameterTypeSet section. "...specifies the bit order, the size in bits, and two algorithms to convert to and from the endcode
    value, along with error detection (CRC and Parity checks).

  • Reported: XTCE 1.2 — Thu, 3 Sep 2020 19:40 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Correct typographical error "endcode" in specification document

    On Page 7, in Section 6.1.2.1, the following text appears:

    BinaryDataEncoding: specifies the bit order, the size in bits, and two algorithms to convert to and from the endcode value, along with error detection (CRC and Parity checks).

    The word "endcode" should read "encoded".

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CustomAlgorithm needs a language/implementation field

  • Key: XTCE13-111
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Perhaps this is more about discussion first but a language/implementation (& version?) attribute would help custom algorithm be useful – and perhaps resolvable by your code.

    For example, since most of the implementations of xtce are java – there are many jvm languages that could run as embedded "script" through the custom algorithm – if we but only knew which one to run!

    For example so called "space python" could be run on jython…

    We use gradle at work, and I'm so used to it forking of JVMs in other languages to do things – I'm thinking, let's give it a go! (we use a plugin that is in written python and is run by gradle on as jython on another jvm)

  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 19:39 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Seems to be correct, there is a language attribute

    After discussion at the September RTF meeting, it appears that this issue may have been a mistake. The desired language attribute does exist.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

ArgumentInputSetType is inconsistent with InputSetType

  • Key: XTCE13-34
  • Status: closed  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    The InputSetType has a InputParameterInstanceRefType as well as a ConstantType.
    The ArguementInputSetType has a InputParameterInstanceRefType as well as a InputArgumentInstanceRefType.
    The inconsistency causes some confusion as to usage.

  • Reported: XTCE 1.2b1 — Wed, 17 Oct 2018 13:24 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Add Constant element back to ArgumentInputSetType complexType

    Propose to restore the access to provided Constant values from the ArgumentInputSetType. There is one other discrepancy in that the Constant cannot be accessed without providing a name. At present, the "constantName" attribute is optional, which means it really cannot be referenced from within the algorithm.

    First we want to make the "constantName" attribute a required field:

    Before:

    <complexType name="ConstantType">
    <annotation>
    <documentation xml:lang="en">Names and provides a value for a constant input to the algorithm. There are two attributes to Constant, constantName and value. constantName is a variable name in the algorithm to be executed. value is the value of the constant to be used.</documentation>
    </annotation>
    <attribute name="constantName" type="string"/>
    <attribute name="value" type="string" use="required"/>
    </complexType>

    After (attribute and annotation update):

    <complexType name="ConstantType">
    <annotation>
    <documentation xml:lang="en">Names and provides a value for a constant input to the algorithm. There are two attributes to Constant, constantName and value. constantName is a variable name in the algorithm to be executed. value is the value of the constant to be used.</documentation>
    </annotation>
    <attribute name="constantName" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Supply a name for the constant to be used to access this value from within the algorithm.</documentation>
    </annotation>
    </attribute>
    <attribute name="value" type="string" use="required">
    <annotation>
    <documentation xml:lang="en">Supply the constant value in the form of the data type needed in the algorithm.</documentation>
    </annotation>
    </attribute>
    </complexType>

    Now we consider adding back the missing Constant element to the ArgumentInputSetType:

    Before:

    <complexType name="ArgumentInputSetType">
    <annotation>
    <documentation xml:lang="en">Identical to InputSetType but supports argument instance references.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    <element name="InputArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference an argument to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    After:

    <complexType name="ArgumentInputSetType">
    <annotation>
    <documentation xml:lang="en">Identical to InputSetType but supports argument instance references.</documentation>
    </annotation>
    <choice maxOccurs="unbounded">
    <element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    <element name="InputArgumentInstanceRef" type="xtce:ArgumentInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference an argument to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    <element name="Constant" type="xtce:ConstantType">
    <annotation>
    <documentation xml:lang="en">Supply a local constant name and value to input to this algorithm.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

    Lastly, correct the missing annotation/documentation in the original InputSetType complexType. This is not a functional change. We should also remove the minOccurs attribute since it is not needed within the choice.

    Before:

    <complexType name="InputSetType">
    <choice maxOccurs="unbounded">
    <element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType"/>
    <element name="Constant" type="xtce:ConstantType" minOccurs="0"/>
    </choice>
    </complexType>

    After:

    <complexType name="InputSetType">
    <choice maxOccurs="unbounded">
    <element name="InputParameterInstanceRef" type="xtce:InputParameterInstanceRefType">
    <annotation>
    <documentation xml:lang="en">Reference a parameter to serve as an input to the algorithm.</documentation>
    </annotation>
    </element>
    <element name="Constant" type="xtce:ConstantType">
    <annotation>
    <documentation xml:lang="en">Supply a local constant name and value to input to this algorithm.</documentation>
    </annotation>
    </element>
    </choice>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

LinearAdjust -- slope should default to 1

  • Key: XTCE13-112
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    This seems an old issue. Slope is optional and intercept is optional. But intercept defaults to 0. Slope has no default. The generated classes then return a Double and double. Seems like slope=1 by default would be a good thing.

    Btw there's a related issue of having this return doubles when they are only being used in non-float number evaluation.

  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 20:39 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Fix the LinearAdjustment element to have an effective default of "no change"

    By setting a default of slope=1 and intercept=0, the element will always default to no change, making it a little cleaner.

    The previous definition for LinearAdjustmentType is:

    <complexType name="LinearAdjustmentType">
    <annotation>
    <documentation xml:lang="en">A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value</documentation>
    </annotation>
    <attribute name="slope" type="double"/>
    <attribute name="intercept" type="double" default="0"/>
    </complexType>

    Modify this complexType element to add the new default value and also to update the annotation.

    <complexType name="LinearAdjustmentType">
    <annotation>
    <documentation xml:lang="en">A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value. The default of slope=1 and intercept=0 results in no change to the value.</documentation>
    </annotation>
    <attribute name="slope" type="double" default="1"/>
    <attribute name="intercept" type="double" default="0"/>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

BinaryContextAlarmList should be ContextAlarmList

  • Key: XTCE13-108
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Type in element name in BinaryParameterType. Possibly a duplicated but I couldnt find it.

  • Reported: XTCE 1.2 — Tue, 21 Apr 2020 16:48 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Mistake in XTCE 1.2 Misnamed Binary Context Alarm Element

    A mistake in the XTCE 1.2 specification work resulted in an element being misnamed. The change was not intended and introduces a gratuitous incompatibility.

    The current XTCE 1.2 complexType for BinaryParameterType extends another complexType named BinaryDataType. Inside of that extension, an element is declared for "BinaryContextAlarmList":

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

    Correct the declared name of the element to be just "ContextAlarmList":

    <element name="ContextAlarmList" 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>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

needs to be updated for items that no longer support hex, octal, binary

  • Key: XTCE13-32
  • Status: closed  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    Items that previously were typed as FixedIntegerValueType but were changed to become long need to be revisited to update the documentation annotation. For instance IntegerDataType initialValue attribute documentation:
    "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."
    Such forms no longer validate against the schema.

  • Reported: XTCE 1.2b1 — Mon, 15 Oct 2018 15:19 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Fix the Parameter/Argument IntegerDataType base 10 documentation miss

    In the schema complexType IntegerDataType, there is an attribute named initialValue:

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

    The intention in XTCE 1.2 was to remove the capability to use the binary, octal, and hex flexibility for specifying the number. In XTCE 1.2, we failed to remove this from the documentation element.

    Modify the attribute to be defined as:

    <attribute name="initialValue" type="long">
    <annotation>
    <documentation xml:lang="en">Default/Initial value is always given in calibrated form. Specify the value as a base 10 integer.</documentation>
    </annotation>
    </attribute>

    For the parallel type, ArgumentIntegerDataType, also apply the identical attribute block replacing the initialValue attribute.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Incorrect MetaCommandRef element definition

  • Key: XTCE13-37
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    Draft version of XTCE v1.2 defined <MetaCommandRef> element as:
    <element name="MetaCommandRef" type="xtce:MetaCommandRefType">
    <complexType name="MetaCommandRefType">
    <annotation>
    <documentation>Describe a reference to a MetaCommand . See NameReferenceType.</documentation>
    </annotation>
    <attribute name="metaCommandRef" type="xtce:NameReferenceType" use="required"/>
    </complexType>

    Published version of XTCE v1.2:
    <element name="MetaCommandRef" type="xtce:NameReferenceType">

    Published version is inconsistent:

    • The attribute "metaCommandRef" is used several other places
    • This is the place where a name reference is element text content instead of an attribute.
  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:26 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    not broken but originally part of List<> clean up issue

    XTCE 1.1 and XTCE 1.2 appear to have the same syntax here. The current copy of the schema shows no change to this element.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Inconsistency in Argument Types with respect to FixedIntegerValueType

  • Key: XTCE13-33
  • Status: closed  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    For instance the documentation for the the ArgumentIntegerDataType says that it is identical to the IntegerDataType. However the initialValue attribute is types as a FixedIntegerValueType whereas the initialValue attribute for the IntegerDataType is typed as long.

  • Reported: XTCE 1.2b1 — Mon, 15 Oct 2018 15:26 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    IntegerDataType and ArgumentIntegerDataType Now Consistent

    This issue appears to have been corrected based on the report of XTCE13-32 with resolution XTCE13-53.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Inconsistent time unit data types

  • Key: XTCE13-39
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XTCE v1.2 added "unit" attribute to TimeAssocationType and added a specialized data type (TimeAssociationUnitType) that is inconsistent with the existing data type (TimeUnitsType)

  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:51 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    aligned time attributes

    Improve the alignment of common values between the TimeUnitsType, TimeAlarmRangesType, TimeAssociationType, and TimeAssociationUnitType. This should include enhancing the documentation.

    First, update the attribute "timeUnits" in the "TimeAlarmRangesType" to match the similar attribute in the complex type "EncodingType". This causes the documentation to match.

    Original definition of the attribute "timeUnits" in "TimeAlarmRangesType":

    <complexType name="TimeAlarmRangesType">
    <complexContent>
    <extension base="xtce:AlarmRangesType">
    <attribute name="timeUnits" type="xtce:TimeUnitsType" default="seconds"/>
    </extension>
    </complexContent>
    </complexType>

    Updated "TimeAlarmRangesType":

    <complexType name="TimeAlarmRangesType">
    <complexContent>
    <extension base="xtce:AlarmRangesType">
    <attribute name="timeUnits" type="xtce:TimeUnitsType" default="seconds">
    <annotation>
    <documentation xml:lang="en">Time units, with the default being in seconds.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Next enhance the documentation for the simple type "TimeUnitsType" and add additional frequently used enumerations for user convenience.

    The original definition:

    <simpleType name="TimeUnitsType">
    <annotation>
    <documentation xml:lang="en">base time units. days, months, years have obvoius ambiguity and should be avoided</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="seconds"/>
    <enumeration value="picoSeconds"/>
    <enumeration value="days"/>
    <enumeration value="months"/>
    <enumeration value="years"/>
    </restriction>
    </simpleType>

    Replace "TimeUnitsType" with this updated definition:

    <simpleType name="TimeUnitsType">
    <annotation>
    <documentation xml:lang="en">Base time unit of measure. It is best practice to avoid days, months, and years due to ambiguity involving leap seconds and leap days. If these are used, the system should document how the leaps are handled.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="seconds"/>
    <enumeration value="milliseconds"/>
    <enumeration value="microseconds"/>
    <enumeration value="nanoseconds"/>
    <enumeration value="picoseconds"/>
    <enumeration value="minutes"/>
    <enumeration value="hours"/>
    <enumeration value="days"/>
    <enumeration value="months"/>
    <enumeration value="years"/>
    </restriction>
    </simpleType>

    To be consistent with the "TimeUnitsType", update the "TimeAssociationUnitType" to match.

    Original definition of "TimeAssociationUnitType":

    <simpleType name="TimeAssociationUnitType">
    <annotation>
    <documentation>Time units the time association decimal value is in.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="si_nanosecond"/>
    <enumeration value="si_microsecond"/>
    <enumeration value="si_millsecond"/>
    <enumeration value="si_second"/>
    <enumeration value="minute"/>
    <enumeration value="day"/>
    <enumeration value="julianYear"/>
    </restriction>
    </simpleType>

    Modified definition of "TimeAssociationUnitType":

    <simpleType name="TimeAssociationUnitType">
    <annotation>
    <documentation>Time units the time association decimal value is in.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="seconds"/>
    <enumeration value="milliseconds"/>
    <enumeration value="microseconds"/>
    <enumeration value="nanoseconds"/>
    <enumeration value="picoseconds"/>
    <enumeration value="minutes"/>
    <enumeration value="hours"/>
    <enumeration value="days"/>
    <enumeration value="months"/>
    <enumeration value="years"/>
    </restriction>
    </simpleType>

    It is then necessary to correct the "TimeAssociationType" to reflect the updates.

    Original definition of "TimeAssociationType":

    <complexType name="TimeAssociationType">
    <annotation>
    <documentation xml:lang="en">Describes a time association consisting of an instance of an absolute time parameter (parameterRef) and this entry. Because telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. See AbsoluteTimeParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterInstanceRefType">
    <attribute name="interpolateTime" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">If true, then the current value of the AbsoluteTime will be projected to current time. In other words, if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to its value before associating this time with the parameter.</documentation>
    </annotation>
    </attribute>
    <attribute name="offset" type="double">
    <annotation>
    <documentation xml:lang="en">The offset is used to supply a relative time offset from the time association and to this parameter</documentation>
    </annotation>
    </attribute>
    <attribute name="unit" type="xtce:TimeAssociationUnitType" default="si_second">
    <annotation>
    <documentation xml:lang="en">Specify the units the offset is in, the default is si_second.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

    Replace with the modified definition of "TimeAssociationType":

    <complexType name="TimeAssociationType">
    <annotation>
    <documentation xml:lang="en">Describes a time association consisting of an instance of an absolute time parameter (parameterRef) and this entry. Because telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. See AbsoluteTimeParameterType.</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:ParameterInstanceRefType">
    <attribute name="interpolateTime" type="boolean" default="true">
    <annotation>
    <documentation xml:lang="en">If true, then the current value of the AbsoluteTime will be projected to current time. In other words, if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to its value before associating this time with the parameter.</documentation>
    </annotation>
    </attribute>
    <attribute name="offset" type="double">
    <annotation>
    <documentation xml:lang="en">The offset is used to supply a relative time offset from the time association and to this parameter</documentation>
    </annotation>
    </attribute>
    <attribute name="unit" type="xtce:TimeAssociationUnitType" default="seconds">
    <annotation>
    <documentation xml:lang="en">Specify the units the offset is in, the default is seconds.</documentation>
    </annotation>
    </attribute>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CNES CCSDS -- unit set "form" question

  • Key: XTCE13-71
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "A new attribute UnitFormType allows to specify a unit for calibrated values and another unit for uncalibrated values.

    Why is this attribute defined with 3 enumerations? ‘raw’, ‘uncalibrated’ and ‘calibrated’?
    "

  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:49 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Improve UnitFormTypes annotation

    Improve the annotation on the UnitFormType to better explain the purpose of the enumerations.

    Original type definition:

    <simpleType name="UnitFormType">
    <annotation>
    <documentation>Optionally specify if this information pertains to something other than the calibrated/engineering value.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="calibrated"/>
    <enumeration value="uncalibrated"/>
    <enumeration value="raw"/>
    </restriction>
    </simpleType>

    Updated type definition:

    <simpleType name="UnitFormType">
    <annotation>
    <documentation xml:lang="en">Defines enumerated values to categorize a unit associated with a telemetered value. Typically the unit refers to the calibrated (engineering) value. In some cases the unit may be associated with the uncalibrated or raw values. Uncalibrated and raw here are typically synonymous, but there are exceptions.</documentation>
    </annotation>
    <restriction base="string">
    <enumeration value="calibrated">
    <annotation>
    <documentation xml:lang="en">The unit of measure for this value refers to the engineer/calibrated value.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="uncalibrated">
    <annotation>
    <documentation xml:lang="en">The unit of measure for this value refers to the pre-calibrated data, after extraction from the data stream, when in the local native data type. This is unusual, but present in some cases.</documentation>
    </annotation>
    </enumeration>
    <enumeration value="raw">
    <annotation>
    <documentation xml:lang="en">The unit of measure for this value refers to the raw binary value from the data stream, prior to conversion to the local native data type and application of calibrators.</documentation>
    </annotation>
    </enumeration>
    </restriction>
    </simpleType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CustomAlarmType has wrong parent

  • Key: XTCE13-67
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The CustomAlarmType appears to extend BaseAlarmType, where as it should just be an extension of InputAlgorithmType (or similar). The result is there are three name attributes to fill in if you want to do so.

    In fact because the AlarmType is the base for all the various DefaultAlarms, the CustomAlarm should probably extend a stubby version of InputAlgorithm without a name or description attribute.

  • Reported: XTCE 1.2 — Tue, 1 Oct 2019 18:42 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    it's right, but ugly

    The issue is what appears to be duplication of attributes. But the way to read it is the Alarm has an optional name, the custom alarm HAS A inputAlgorthm – and this could have it's own name.

    this all came about because the alarms now have a common base ... which includes an optional name.

    So while a little ugly or even confusing ... it's right.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

ByteOrderList is invalid for Containers

  • Key: XTCE13-29
  • Legacy Issue Number: 14517
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2009-09-10 22:59:58 BST
    ByteOrderList is not valid for container and is part of the BinaryEncoding
    element.

    Ignore or remove from future version.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Make a new schema type called ContainerBinaryDataEncoding

    Make a new schema type called ContainerBinaryDataEncoding and remove the bitOrder and ByteOrder from it. Then replace the reference to the BinaryDataEncodingType in the ContainerType area.

    The new schema type:

    <complexType name="ContainerBinaryDataEncodingType">
    <annotation>
    <documentation xml:lang="en">Describe container 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>
    <sequence>
    <element name="ErrorDetectCorrect" type="xtce:ErrorDetectCorrectType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">Describes the optional inclusion of an error detection and/or correction algorithm used with this container.</documentation>
    </annotation>
    </element>
    <element name="SizeInBits" type="xtce:PositiveLongType">
    <annotation>
    <documentation xml:lang="en">Number of bits this container occupies on the stream being encoded/decoded. This is only needed to "force" the bit length of the container to be a fixed value. In most cases, the entry list would define the size of the container.</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>
    </complexType>

    The changes:

    Original -->

    <complexType name="ContainerType" abstract="true" mixed="false">
    <annotation>
    <documentation xml:lang="en">An abstract block of data; used as the base type for more specific container types</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <annotation>
    <documentation xml:lang="en">RateInStream is used to: a) generate alarms when the Container is updated too frequently or too infrequently, b) provide some 'guidelines' for generating forward link containers, c) provide some guidelines for spacecraft simulators to generate telemetry containers. If necessary, these rates may be defined on a per stream basis.</documentation>
    <appinfo>The software should check that any Stream names referenced in the RateInStreamSet actually exist.</appinfo>
    </annotation>
    <element name="DefaultRateInStream" type="xtce:RateInStreamType" minOccurs="0"/>
    <element name="RateInStreamSet" type="xtce:RateInStreamSetType" minOccurs="0"/>
    <element name="BinaryEncoding" type="xtce:BinaryDataEncodingType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">May be used to indicate error detection and correction, change byte order, provide the size (when it can't be derived), or perform some custom processing.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

    Changes -->

    <complexType name="ContainerType" abstract="true" mixed="false">
    <annotation>
    <documentation xml:lang="en">An abstract block of data; used as the base type for more specific container types</documentation>
    </annotation>
    <complexContent>
    <extension base="xtce:NameDescriptionType">
    <sequence>
    <annotation>
    <documentation xml:lang="en">RateInStream is used to: a) generate alarms when the Container is updated too frequently or too infrequently, b) provide some 'guidelines' for generating forward link containers, c) provide some guidelines for spacecraft simulators to generate telemetry containers. If necessary, these rates may be defined on a per stream basis.</documentation>
    <appinfo>The software should check that any Stream names referenced in the RateInStreamSet actually exist.</appinfo>
    </annotation>
    <element name="DefaultRateInStream" type="xtce:RateInStreamType" minOccurs="0"/>
    <element name="RateInStreamSet" type="xtce:RateInStreamSetType" minOccurs="0"/>
    <element name="BinaryEncoding" type="xtce:ContainerBinaryDataEncodingType" minOccurs="0">
    <annotation>
    <documentation xml:lang="en">May be used to indicate error detection and correction, change byte order, provide the size (when it can't be derived), or perform some custom processing.</documentation>
    </annotation>
    </element>
    </sequence>
    </extension>
    </complexContent>
    </complexType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Clean up semantics of "OO-Include Condition"

  • Key: XTCE13-28
  • Legacy Issue Number: 14509
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:45:18 BST
    In EntryList, a containerRef that's to an abstract container has special
    meaning. perhaps it warrants it own entry to clear up the semantics.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    EntryList containerRef feature already exists

    It is reasonable and it has been done already. Users can insert an abstract ContainerEntryRef in an EntryList and that works. The expected behavior is that the container will evaluate the same as if it were in a stream.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CNES CCSDS -- inside/outside range support in ValidRange

  • Key: XTCE13-70
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "The issue is partially fixed. The new attribute rangeForm shall be also used in ValidRange and not only in AlarmRangesType.

    The use of this new attribute allows to simplify the definition of ranges (in replacing minInclusive, maxInclusive, minExclusive and maxExclusive with min & max)."

  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:45 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    The inside/outside flag does not interact with ValidRange – annotation improved

    The authors are concerned that the purpose of ValidRange may be misinterpreted and propose to improve the annotation. It is not yet conceived or seen that a ValidRange could have an "inside" or "outside" rangeForm use case, although we are open to be shown an example if this is truly needed.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CNES CCSDS -- Time ParameterType inheritance may need to be repolled

  • Key: XTCE13-68
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    An issue marked as deferred in 1.1, made into 1.2.

    "Type inheritance missing from Absolute and Relative time data types

    The status of this issue is ‘Deferred’ but the proposed change has been implemented in 20180204-SpaceSystemV1.2.xsd"

  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:40 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    repoll the Time Inheritance issue to formally accept the change

    This is a mistake in XTCE 1.2 finalization, although the community considers it a desired one. This resolution proposes that we formally accept this change by vote. As a result, there is no change in XTCE 1.3. This is the original issue:

    https://issues.omg.org/issues/XTCE12-14

  • Updated: Tue, 1 Jul 2025 15:05 GMT

MemberType and ComparisonType annotation misses fix to value formatting

  • Key: XTCE13-91
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    In the MemberType element, the initialValue attribute missed the annotation fix to remove the "0b" and "0x" stuff from previous discussions and resolution in XTCE 1.2.

  • Reported: XTCE 1.2 — Sat, 12 Oct 2019 19:45 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Correct Value Descriptive Annotation in MemberType and ComparisonType

    Propose to correct the documentation in the schema to make these consistent with previous changes.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

ServiceRef construction error

  • Key: XTCE13-31
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The service ref now require content and an attribute – this clearly the result of an "oops" during clean up of 1.2.

    Basically it should NOT extend NameDescriptionType.

    <complexType name="ServiceRefType">
    <annotation>
    <documentation xml:lang="en">A reference to a Service</documentation>
    </annotation>
    <simpleContent>
    <extension base="xtce:NameReferenceType">
    <attribute name="serviceRef" type="xtce:NameReferenceType" use="required"/>
    </extension>
    </simpleContent>
    </complexType>

  • Reported: XTCE 1.2 — Mon, 14 May 2018 17:35 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Cleanup extra extensions from NameReferenceType

    The reporter is correct in that there is a gratuitous extension in the schema for ServiceRefType. This will be cleaned up. The change here is not functional from the XTCE document standpoint. The document will be same.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CNES CCSDS -- RelativeTimeAgument typo

  • Key: XTCE13-69
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "Some typos have been fixed (twosComplement instead of twosCompliment & onesComplement instead of onesCompliment) but one is still present in the schema: RelativeTimeAgumentType instead of RelativeTimeArgumentType."

  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:43 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    Duplicate of Issue Reported in XTCE13-36

    This issue was previously reported in XTCE13-36 and a resolution has been proposed under XTCE13-80. The committee intends to make this correction as specified by the reporter.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

RelativeTimeAgumentType is misspelled

  • Key: XTCE13-36
  • Status: closed  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    <element name="RelativeTimeAgumentType" type="xtce:RelativeTimeArgumentType">
    RelativeTimeAgumentType should have an "r" in it.

  • Reported: XTCE 1.2b1 — Thu, 18 Oct 2018 19:22 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Correct Misspelled RelativeTimeAgumentType

    The element "RelativeTimeAgumentType" should be "RelativeTimeArgumentType".

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Unecessary Sequence of choice in AlarmType

  • Key: XTCE13-66
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Just a typo in the schema construction, should just be optional choice.

    <sequence>
    <choice minOccurs="0">
    <element name="AlarmConditions" type="xtce:AlarmConditionsType">
    <annotation>
    <documentation xml:lang="en">A MatchCriteria may be specified for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true.</documentation>
    </annotation>
    </element>
    <element name="CustomAlarm" type="xtce:CustomAlarmType">
    <annotation>
    <documentation xml:lang="en">An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter.</documentation>
    </annotation>
    </element>
    </choice>
    </sequence>

  • Reported: XTCE 1.2 — Tue, 1 Oct 2019 18:22 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Correct Schema Construction For AlarmType

    The construction of the AlarmType complexType in the schema has a redundant sequence and choice model. This should be removed. There is no impact to the XTCE XML documents in this case. It appears that this is restoring XTCE v1.2 to XTCE v1.1 schema construction.

    In addition, the choice of 1 of the elements will be made required so that the parent element, which is optional, requires content if it is chosen to be included. Including an empty element does not make technical sense.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

ArgumentAssigmentList in the MetaCommandStep is misspelled

  • Key: XTCE13-35
  • Status: closed  
  • Source: Peraton ( Victoria Vickers)
  • Summary:

    This should be ArgumentAssignmentList, with an "n".

  • Reported: XTCE 1.2b1 — Thu, 18 Oct 2018 17:03 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Correct Spelling Error of ArgumentAssigmentList in MetaCommandStepType

    Within the schema MetaCommandStepType definition, the element ArgumentAssigmentList is missing the "n" and should be spelled as ArgumentAssignmentList.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add gap entry to container entry list

  • Key: XTCE13-5
  • Legacy Issue Number: 19384
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A gap entry is an addressing mechanism to move the address pointer relative or absolutely as specified in the gap entry. This is an alternate approach to XTCE's location in container element. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Gap Entries For Sequence Container Not Needed

    The original reporter for this issue has suggested that the driver for this is obsolete. Further discussion by the committee has not identified a need for this with the current syntax being completely able to capture gaps, albeit in a slightly different way. Propose to close this without change.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Duplicated BaseCalibratorType extension

  • Key: XTCE13-40
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XTCE 1.2 defined as base data type for calibrators (BaseCalibratorType).
    This data type is used an extension twice for each calibrator:

    • Once in CalibratorType
    • Again in the child element (e.g., PolynomialCalibratorType)
  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:58 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    BaseCalibratorType usage was intended

    The BaseCalibratorType defines attributes of a name, shortDescription, and an element of AncillaryData. This is used in CalibratorType and all 3 of the Calibrators that can appear in that element.

    In the XTCE 1.2 RTF this was discussed. It was chosen to keep this added flexibility although it does seem to be redundant.

    For implementers, when a calibrator can be named and documented with a description, the most specific one (in the specific Calibrator element) should be preferred over the higher level one in the Calibrator or DefaultCalibrator element if both exist in the XTCE document.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Type inheritance missing from Absolute and Relative time data types

  • Key: XTCE13-1
  • Legacy Issue Number: 19633
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Absolute and Relative time should have a "baseType" similar to the other scalar data types. This is probably an oversight.

  • Reported: XTCE 1.1 — Mon, 6 Oct 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Base Time Data Types were previously added

    In a previous resolution, BaseTimeDataType and ArgumentBaseTimeDataType were applied to AbsoluteTime and RelativeTime Parameter and Argument types. In addition, all 4 do contain the baseType attribute. It appears that this issue has been overcome by events.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Spelling error for Arguments in XTCE 1.2 proposed

  • Key: XTCE13-22
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    Reported by Michel Sibon of Thales. There is a spelling error of the word "Agument" in RelativeTimeArgumentType in XTCE 1.2 proposed. It has been present for some time because it is also reflected in the xtcetools schema file that was based on an early XTCE 1.2 releae schema.

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

    The text above is from the RTF report version of the file.

  • Reported: XTCE 1.1 — Tue, 20 Mar 2018 12:18 GMT
  • Disposition: Duplicate or Merged — XTCE 1.3
  • Disposition Summary:

    Duplicate of other Argument spelling issue

    The spelling error for RelativeTimeArgumentType is also recorded in XTCE12-36. We will address in that issue.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Re-evaluate the characterWidth attribute in String types

  • Key: XTCE13-26
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    I am not sure that this attribute makes sense in the String data type definitions. The character encoding (@encoding) element really should capture the knowledge here, but there could be a nuance I am unsure about.

    Check on this in the committee meeting. Propose to remove the attribute.

  • Reported: XTCE 1.1 — Sat, 9 Sep 2017 18:22 GMT
  • Disposition: Resolved — XTCE 1.3
  • Disposition Summary:

    Fix ambiguity with characterWidth attribute

    At present, the characterWidth attribute on BOTH the complexType definitions of StringDataType and ArgumentStringDataType is undocumented and as a result not particularly clear. The proposal is to replace the attribute definition of:

    <attribute name="characterWidth" type="xtce:CharacterWidthType"/>

    With a new definition containing annotation/documentation of:

    <attribute name="characterWidth" type="xtce:CharacterWidthType">
    <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 encoding information for the string, but it is not always clear, so this attribute allows the extra hint when needed. A tolerant implementation will endeavor to always make sufficient size engineering data types to capture the entire range of possible characters.</documentation>
    </annotation>
    </attribute>

    Lastly, the simpleType "CharacterWidthType" misses the possibility that a 32 bit character width is used. Propose to change the existing:

    <simpleType name="CharacterWidthType">
    <restriction base="integer">
    <enumeration value="8"/>
    <enumeration value="16"/>
    </restriction>
    </simpleType>

    To the following definition by adding a value of 32 to the list:

    <simpleType name="CharacterWidthType">
    <restriction base="integer">
    <enumeration value="8"/>
    <enumeration value="16"/>
    <enumeration value="32"/>
    </restriction>
    </simpleType>

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Elevate annotation specifying time string formats to an attributes

  • Key: XTCE13-7
  • Legacy Issue Number: 19376
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The annotation below would be better served as an optional attribute with the specified format as the default. From a telemetry stantpd this would be interpreted as optional display info, and from an argument standpt the user input string format. "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. "

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Time Format is Implementation Configuration

    It appears to be the consensus from the January 2019 technical meeting that time formats for display purpose are an implementation for the ground system rather than something attached to the time type. At this time we propose to leave this to the implementing system.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add OCL specific Algorithm to XTCE

  • Key: XTCE13-12
  • Legacy Issue Number: 14507
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:41:50 BST
    OCL is an OMG standard that adds a constraint language to UML or any model.
    It's related to RestrictionCriteria. Would a specific XTCE Algorithm for OCL
    be useful?

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Closed; No Change — XTCE 1.3
  • Disposition Summary:

    Adding OCL feature in containers scopes to a 2.0 proposal

    The request for an OCL construct in the RestrictionCriteria element is a significant change to the XTCE data model. This is not something we expect to do in the foreseeable future.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add switch entry to container entry list

  • Key: XTCE13-3
  • Legacy Issue Number: 19385
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A switch entry is similar to the switch/case statement provided in most programming languages, and would improve upon the include condition currently found in XTCE. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Switch/case feature in containers scopes to a 2.0 proposal

    The request for a switch/case construct in the container EntryList element is a significant change to the XTCE data model. This type of change cannot be done by a minor revision task force. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Expand features to include common industry encodings in StreamsSet

  • Key: XTCE13-2
  • Legacy Issue Number: 19386
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Added specific support for reed-solomon and turbo encoding, among others in the stream set. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Defer StreamSet Enhancements

    The StreamSet element needs significant enhancement. We plan to do this, but do not have the resources to do this in the 1.3 version timeframe. The document attachment is helpful and will be taken into account.

  • Updated: Tue, 1 Jul 2025 15:05 GMT
  • Attachments:

Provide way to categorize all elements with @name into one or more groups

  • Key: XTCE13-4
  • Legacy Issue Number: 19381
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Outside of the SpaceSystem and systemName, a general mechanism for categorizing @name elements into one or groups is needed. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Additional groups feature for names scopes to a 2.0 proposal

    The request for another @name grouping feature appears to be a simple addition to the XTCE data model, but the handling of this for vendors is not quite clear at this time. This type of change should not be done by a minor revision task force. This should be handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add variable to containers

  • Key: XTCE13-6
  • Legacy Issue Number: 19382
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Variables are local values created from bit/sub-bits specified in the entry list of container. They are similar to parameters but exist only within the scope of the container they are defined – they are of type integer. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Variables feature in containers scopes to a 2.0 proposal

    The request for a defining variables in the container EntryList element is a significant change to the XTCE data model. This type of change cannot be done by a minor revision task force. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Need support for mask alarm

  • Key: XTCE13-9
  • Legacy Issue Number: 19371
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    A mask alarm applies to numerics and enums – although usage in floats is discouraged. It defines 16-states which map 1 to 1 with values (say 1-16), it's a 16-bit mask – each bit is either a care or don't care. If set to 1, it's a care bit. If the value associated with that bit appears, it is in alarm. If the mask bit is set to 0, it's a don't care bit – and the value associated with it will not trip an alarm. When used with enums it's almost like an enum alarm list,except the states can go "past" the range of values given in the enum list itself. For example, suppose an enum had the values of OPEN=1, SHUT=2. The mask could be 0xfffffffc - as one and two are allowed and valid. And any other value would be in alarm. Because there's only two enum values and each of these is green but any other value is read, it is hard to completely simulate this alarm with the enum alarm list. It's possible to use a condition perhaps in this one example but the current syntax requires the enum alarm list. Further transferring this information through to another party will be hard in that case. Reported by JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Mask alarm concept better scopes to a 2.0 proposal

    The request for a mask alarm adds a new feature to XTCE that is currently an implied feature by many vendors. To consider this, it would be better to scope it to a 2.0 type of proposal rather than the 1.3 maintenance release. In addition, the original issue reporter suggests that the feature may no longer be used by their implementation.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add ArgumentTypeSet to MetaCommand

  • Key: XTCE13-8
  • Legacy Issue Number: 19377
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Allow for local argument types to be defined in MetaCommand, helps avoid collisions with arguments in other commands of the same name but different properties.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Local Argument Types in MetaCommand scopes to a 2.0 proposal

    The request for a local argument type element possibility within MetaCommand is a significant change to the XTCE data model. This type of addition should not be done by a minor revision task force. This should be something that is handled by a potential 2.0 RFP.

    Collisions are handled by assigning unique names to argument types.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Re-architect XTCE alarm model

  • Key: XTCE13-10
  • Legacy Issue Number: 19369
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    XTCE alarms are associated with data types and come in a default and context set form. A variety of alarm types are associated with each data type, some specific to it (such enum alarms). However this is too restrictive to meet the needs of many of organizations. Specifically the following is requested: allow set of alarms without a required context by data type. Original reporter is JPL.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Alarm Architecture Needs To Be 2.0 Proposal

    There are valid concerns with the design of the alarm definitions in v1 of XTCE. There are ongoing discussions on this topic. The consensus of the committee is that this change should be in a 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Should RestrictionCriteria should be assignment not operators for Commanding?

  • Key: XTCE13-11
  • Legacy Issue Number: 14506
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:39:55 BST
    RestrictionCriteria seems incorrect for commands. the value checked are
    inserted to form the command, operators seem a little strange, maybe only '=='
    makes sense, etc...

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Changing RestrictionCriteria in MetaCommand scopes to a 2.0 proposal

    The point is well noted that the RestrictionCriteria element for MetaCommand definitions seems to be an awkward construct, although it is in use by end users and vendors for the intended purpose. This type of change cannot be done by a minor revision task force. It would not be backwards compatible and some work for implementers to change this where a "bug" does not really exist. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

CustomAlgorithm should be "typed" reference to AlgorithmSet

  • Key: XTCE13-13
  • Legacy Issue Number: 14505
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-05-28 21:35:39 BST
    CustomAlgorithm which appears in many places in the schema should be a
    namereference to AlgorithmSet. To enforce the proper semantics the Ref should
    "name" which algorithm type it referes to such as "InputAlgorithmRef" or
    "InputOutputAlgorithmRef", etc...

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Major syntax change, but existing works

    Similar to other proposals to move alarms and calibrators to set, and then refer to them as needed similar to other things in the schema.

    The changes required are significant in nature and the existing works. There are no use cases presented by anyone that shows they cannot use the existing as is – even if they don't like it.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Expand NameReference semantics

  • Key: XTCE13-14
  • Legacy Issue Number: 14489
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2008-03-04 22:57:09 GMT
    Expand NameReference concept to allow specifying items in precise locations
    such as TelemetryMetaData, CommandMetaData, etc...

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Expanding NameReference scopes to a 2.0 proposal

    The request to consider expanding NameReference beyond the original XTCE concept is a very significant change to the XTCE data model. This type of change cannot be done by a minor revision task force. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

Add forward/reverse calibrator metadata

  • Key: XTCE13-15
  • Legacy Issue Number: 14473
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:48:47 BST
    Some organizations wish to capture counts to units on the telemetry side & then
    units to counts on command side (often called reverse or inverse calibrators).
    In some cases they may wish to both for various reasons, often in testing
    scenarios to validate their operation calibration. XTCE does not provide an
    easy way to mark a calibrator as either 'reverse' or 'forward'.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Bi-directional calibrators scopes to a 2.0 proposal

    The request to add forward/reverse calibration to types is a significant change to the XTCE data model. This type of change is useful, but should not be done by a minor revision task force. It is also a challenge for the vendors at this time such, even if XTCE supported this feature. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:05 GMT

AbsoluteTime should have Alarms

  • Key: XTCE13-16
  • Legacy Issue Number: 14466
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:37:38 BST
    AbsoluteTimeParameterType do not have alarm elements associated with it. In
    the current schema this may be by design – an example of a usage for an
    alarming absolute time could be helpful. JWST claims to alarm on occurrences
    of reverse time which in fact would probably be a packet ordering issue.

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Alarms on AbsoluteTime Interesting But Need Design

    We propose to continue to defer the idea of adding alarm definitions to AbsoluteTime parameters because we do not have any extant examples of this. It is a good idea, but needs to be designed. Perhaps a change/delta alarm capability would be useful here. Further end user community input is welcome and desired.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Checkwindow not tied to context

  • Key: XTCE13-17
  • Legacy Issue Number: 14458
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:09:15 BST
    CheckWindow has no way to vary window size based on context

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    defer – lacking real world uses cases that current is broken

    Ok the background this an observation but with no known use cases. Given that i think we could rightly defer. However the observation is that your context verifier check windows may well be tied to a context and even though there's a way to have many verifiers in some cases (execution and complete) of the same kind – there's no built in way to say: "When I'm in X context, do this check – but when I'm in Y context, do this check." One could perhaps cobble up a solution by naming the verifiers and that has some meaning only to you – "ExecutionContextX" and "ExecutionContextY". The other way that comes to mind is to provide a ref to the context in the verifier, perhaps just a local ref – and put an optional name attribute in the context that can be ref'd – allowing for the association...

    But that's all just a lot of speculation really & so defer seems best to me unless someone can cough up a real world example that does not work with current at all.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

List and List> clean up needed
  • Key: XTCE13-24
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    After jaxb runs on the current XTCE 1.2 (after ballot 28) schema. The following methods show weaknesses in the schema type hierarchy (below). It's been shown they schema types can be meaningfully tweaked and these items will map cleanly. It also suggest but is not clear the order of the items in some the lists may not be enforced. for two of the items below this would be bad. this is conjecture however.

    >> ArgumentInputSetType.java: public List<Object> getInputParameterInstanceRefOrInputArgumentInstanceRef() {
    >> InputSetType.java: public List<Object> getInputParameterInstanceRefOrConstant() {
    >> ParameterSetType.java: public List<Object> getParameterOrParameterRef() {
    >>
    >> ArgumentComparisonCheckType.java: public List<JAXBElement<?>> getRest() {
    >> ComparisonCheckType.java: public List<JAXBElement<?>> getRest() {
    >> MathOperationCalibratorType.java: public List<JAXBElement<?>> getValueOperandOrThisParameterOperandOrOperator() {
    >> MetaCommandSetType.java: public List<JAXBElement<?>> getMetaCommandOrMetaCommandRefOrBlockMetaCommand() {
    >>

  • Reported: XTCE 1.1 — Wed, 14 Feb 2018 17:43 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Defer the resolution

    Defer consideration for a later minor revision of XTCE

  • Updated: Tue, 1 Jul 2025 15:04 GMT
  • Attachments:

Message/IncludeCondition/BaseContainer similarity

  • Key: XTCE13-18
  • Legacy Issue Number: 14460
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:11:43 BST
    Message, IncludeCondition and BaseContainer do similar things and should be
    unified
    Comment 1 Kevin Rice 2007-10-22 21:21:03 BST
    Message, IncludeCondition and BaseContainer do similar things and should be
    unified

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Message/IncludeCondition/BaseContainer scopes to a 2.0 proposal

    The request to reconsider the Message, IncludeCondition, and BaseContainer elements is a significant change to the XTCE data model. This type of change cannot be done by a minor revision task force. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

lack of Union construct (MER + ASIST)

  • Key: XTCE13-20
  • Legacy Issue Number: 8909
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    MER supports a Union construct because their abstract data types live past decomm. ASIST also supports the same idea – that an abstract data type onboard the spacecraft MAY live past decomm. Although it is possible to let multiple parameters overlap, in a sense allowing for a Union in XTCE. The issue arises that validating software cannot differentiate this with a bug in a container specification. A union tag or element of some sort is needed.

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Union types scopes to a 2.0 proposal

    The request for a Union data type is a significant change to the XTCE data model. This type of change cannot be done by a minor revision task force. This would need to be something that is handled by a potential 2.0 RFP.

    Unions can be implemented in XTCE using the Container EntryList, although the issue correctly points out that it is hard to programmatically verify.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Move Alarms outside of Type Area

  • Key: XTCE13-19
  • Legacy Issue Number: 14454
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Description Kevin Rice 2007-10-22 21:04:10 BST
    Move Alarms outside of Type area. Alarms may change a lot and it may be easier
    to have them set in the Parameter area, further alarms and calibrators, as well
    as the time types reference Parameters directly which seems inconsistent with
    them being in types.

    C-S/CNES
    Ludovic Faure

  • Reported: XTCE 1.1 — Thu, 17 Sep 2009 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Moving Alarms and/or Calibrators to Separate Sets Deferred

    Adding an extension to the specification to define Alarm and Calibrator data outside of the Parameter and/or Argument Type area is a wise idea. There is support for this, but not resources to devote in the 1.3 timeframe. We propose to defer this to the next revision.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

inability to describe sets of limits (alarms) and conversions (polynomials)

  • Key: XTCE13-21
  • Legacy Issue Number: 8908
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    inability to describe sets of limits (alarms) and conversions (polynomials) and then select a set per parameter depending on mission phase (JWST)

    JWST hold conversion and limits in a seperate file that are grouped. Certains "sets" can be used for different mission phases such as test, on-orbit and so on, or for any reason deemed appropriate. XTCE allows one to specify at MOST one of each of these per parameterType

  • Reported: XTCE 1.0b1 — Tue, 21 Jun 2005 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    use context alarms

    contextalarms could be managed into a form of sets by having a primary enabling condition check used against all alarm definitions. does nothing for default alarm though which could be simply not used (& would have to appear if such exists in the context list somehow). i think because there's a perhaps cumbersome work around, defer.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Add event message support

  • Key: XTCE13-25
  • Legacy Issue Number: 19388
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Even message support is need in XTCE. Adding an EventSet to TelemetryMetaData would be an appropriate location.

  • Reported: XTCE 1.1 — Wed, 30 Apr 2014 04:00 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Events not in scope, no agreement

    Two issues with this one push into defer. Firstly, it's (probably) not within the original scope of the XTCE RFP. Secondly there no complete agreement on what this means – some mean a message from the spacecraft, whereas other means a ground side message.

    Given that, it should (probably) be deferred for some "XTCE 2.0" RFP.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Cleanup Container EntryList element by deprecating IndirectParameterRefEntry

  • Key: XTCE13-27
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The IndirectParameterRefEntry is a clever construct that has the potential to be useful, although I am not aware of anyone who has used it.

    I suggest that we consider removing it because it is a limited case of the more general case solved by the IncludeCondition element. The IncludeCondition can provide this functionality and a lot more. As a result, this element is effort for implementers that doesn't add anything really "new". In addition, it leaves a case where the need is addressed in more than 1 way - which is generally not the best idea.

  • Reported: XTCE 1.1 — Tue, 30 May 2017 23:44 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    IndirectParameterRefEntry scopes to a 2.0 proposal

    The request for modification of the IndirectParameterRefEntry element is a not a backwards compatible change to the XTCE data model. This type of change cannot be done by a minor revision task force. This would need to be something that is handled by a potential 2.0 RFP.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

lost annotation in 1.2 inputAlgorithmType schema type rework

  • Key: XTCE13-65
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Much of the annotation is gone in InputAlgorithmType in 1.2 in its major elements. These were turned into schema types for 1.2, and somehow the annotation was not copied over from 1.1.

  • Reported: XTCE 1.2 — Fri, 27 Sep 2019 15:07 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Defer the resolution

    Defer consideration for a future minor revision of XTCE

  • Updated: Tue, 1 Jul 2025 15:04 GMT

CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer

  • Key: XTCE13-72
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    "The issue is declared Closed.
    The problem has not been fixed. It is still impossible to reference an argument in a CommandContainerSet/CommandContainer/RefEntry."

  • Reported: XTCE 1.2 — Wed, 2 Oct 2019 14:54 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Defer the resolution

    Defer consideration of this issue for a later minor revision of XTCE

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Missing default value of dataSource attribute

  • Key: XTCE13-38
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    Draft version of XTCE v1.2 defined dataSource attribute as:
    <attribute name="dataSource" type="xtce:TelemetryDataSourceType" default="telemetered">

    Published version is v1.1:
    <attribute name="dataSource" type="xtce:TelemetryDataSourceType" use="optional">

  • Reported: XTCE 1.2 — Fri, 22 Feb 2019 21:37 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Keep dataSource attribute as defined in v1.1/v1.2

    This issue (XTCE13-38) was written based on a comparison between draft version of XTCE v1.2 and the released version. Further analysis suggests that the released version (no default value) is good as is and no further action should be taken.

    The idea of providing a default value of "telemetered" for dataSource was tied to other proposed changes to the Parameter element. In the absence of these changes, providing a default value may conflict with other mechanisms to indicate the data source (e.g., using a parameter naming convention).

  • Updated: Tue, 1 Jul 2025 15:04 GMT

parametertype and argumenttype type hiearchies still need work

  • Key: XTCE13-113
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    This is more for discussion. our syntax is ok but when the schema types that control the syntax in parameter/argument type are manifest into classes, the result is less than ideal.

    Firstly all our parametertype/argumenttypes have NameDescriptionType as the root. It might for example make sense to have as a root "DataType" or something of that nature – and maybe to then ScalarDataType and ComplexDataType which seems natural.

    Secondly we now have split the parameter type and argument types because we had to support looking up parameters and arguments in the latter. And these appear deep in the syntax trees. More ideally we'd just bolt on those latter in the hierarchy so as to show more schema types.

    Finally somehow array and aggregate didn't get the message – and the time types have their own data encoding syntax.

    The result is this:

    BaseDataType – all the scalars on the parameter type side have this as a parent.

    XXXDataType – next up the various scalars have this interim schema type. This is a vestige from 1.1. So for example IntegerDataType.

    BaseTimeDataType – absolute and relative use this though.

    ArrayDataTypeType and AggregateDataType – array and aggregate follow this line

    Then on the argument side, this is mirrored but with "argument" stuck in front of it all:

    ArgumentBaseDataType, ArgumentBaseTimeDataType – oddly Array and Aggregate on this side have ArrayDataTypeType and AggregateDataType as parents.

    In the end we up with lots of "root" schema types that are all children of NameDescriptionType – BaseDataType, BaseTimeDataType, ArgumentBaseDataType, ArgumentTimeBaseDataType, ArrayDataTypeType and AggregateDataType.

    There's no DataType, ScalarDataType or ComplexDataType which might more natural organize it.

    Conclusion: this could all be better.

  • Reported: XTCE 1.2 — Fri, 10 Jul 2020 11:28 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Consider type hierarchy modifications in a 2.0 context

    At the September RTF, it was decided to defer this to a later RTF or 2.0 level modification of XTCE. We are carrying this forward because it is a good idea.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Dynamic look up should have integer and float forms

  • Key: XTCE13-109
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Dynamic lookup is sprinkled about the text to (only?) retrieve a numeric value but perhaps there should be an integer and float form. For example in calculating a dynamic array index, would it make sense if the referred to parameter is a float? we can agree any non-numeric is a error. If it's a float or integer, the slope and intercept are doubles – suggesting a double result. Well that may produce a fractional value of an array index – that doesn't make sense. one can round or chop as one sees fits but that's not documented. in this case integer only dynamic value would make more sense – the slope and intercept would be int/long and it would be in error to ref anything but an integer parameter type. other cases may allow for either data type. [edit] Discrete lookup DOES NOT have the same issue – it's value is a float. It however does need a default. I made an issue for that.

  • Reported: XTCE 1.2 — Thu, 9 Jul 2020 19:22 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Reballot: Integer versus Float lookups could be a 2.0 enhancement

    This issue is clearly annoying to the perfectionist, but an implementation can make an assumption that is reasonable and proceed. It is proposed to defer this to a later revision of XTCE.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm should be allowed for all data encodings

  • Key: XTCE13-124
  • Status: closed  
  • Source: Space Applications Services ( Nicolae Mihalache)
  • Summary:

    Currently the FromBinaryTransformAlgorithm/ToBinaryTransformAlgorithm are allowed only for BinaryDataEncodingType with the comment "Used to convert binary data from an application data type to binary data". However the binary data encoding is used to encode/decode binary data, so not any application data (float, integer, time,...).

    We believe it is more beneficial to allow these algorithms to all data encoding types.

    For example a FromBinaryTransformAlgorithm attached to a IntegerDataEncoding can extract a varint like the ones used in protobuf (https://developers.google.com/protocol-buffers/docs/encoding#varints).

    Similarly a ToBinaryTransformAlgorithm attached to a FloatDataEncoding can be used to encode a floating point number in an exotic format; for example bfloat16 is commonly used in AI chips (https://en.wikipedia.org/wiki/Bfloat16_floating-point_format)

  • Reported: XTCE 1.2 — Thu, 22 Apr 2021 07:57 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Extra data encoding not needed - instead use integer or float

    The committee recognizes that there might be a need here with emerging technologies, but not enough is available at this time to make a concrete and useful change.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Revert change to CalibratorType base type

  • Key: XTCE13-107
  • Status: closed  
  • Source: Northrop Grumman ( Mr. Joseph Vlietstra)
  • Summary:

    XUSP 1.2 changed the base type of CalibratorType from OptionalNameDescriptionType to the new BaseCalibratorType. This change eliminated the previous support for <LongDescription> and <AliasSet>. These elements are supported in the XUSP 1.0 profile and are used in existing databases.

  • Reported: XTCE 1.2 — Wed, 25 Mar 2020 20:07 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Defer the resolution

    Defer consideration for a future XTCE minor revision

  • Updated: Tue, 1 Jul 2025 15:04 GMT

FixedValueEntry, maybe it's not as good as it could be

  • Key: XTCE13-137
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    FixedValueEntry has a hard coded hexBinary value that's supposed to be in "spacecraft order". There's a now optional name in 1.2.

    ITOS and ASIST capture the same info slightly differently. The value is in human-readable form, (e.g "5331" or whatever it is that you can read and understand). But Bit/Byte order are provided as modifiers to the field/entry definition so that the software will do the right thing and encode it properly for the final destination on the spacecraft. ITOS/ASIST require the name and other associated the meta data for these fields.

    So there's similarities overall between them but the encoding aspect is the key difference.

    The upsides to their approach are (there may be more):

    • when you see the definition, it makes some sense to you
    • the software takes care of the encoding and in a way it is then documented as to what is the both the value is and how it's going to be encoded for the final destination.

    The downsides are (could be more):

    • well something will have to be done to see the final bit values ...
    • there's more to write out to build the definition

    Is there a case to be made to change, or modify the existing fixedvalueentry? What would the approach be?

    1) maintain pure backwards compatibility: add a second variation "uservalueentry" that supplies it as described above and includes a local bit/byteorder
    2) modify fixedavalueentry itself and keep a kind of conceptual compatibility...

    What do you think?

  • Reported: XTCE 1.2 — Tue, 14 Nov 2023 16:15 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    Defer changes to FixedValueEntry

    Other systems have noted convenience concerns with specifying the value of this element. At present, there doesn't appear to be a good intersection, but if one can be found, it may make sense to update this element.

  • Updated: Tue, 1 Jul 2025 15:04 GMT

Add an optional attribute to ComparisonList to make it all ORs

  • Key: XTCE13-141
  • Status: closed  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    For some reason this idea flew into my funnel this morning. I was looking at the ComparisonList and noticed the annotation to it said there's an implied 'and' between all the comparisons in the list.
    I then thought: Why not add an attribute to override that to set to it all ORs? Why would that be a bad thing?
    Unable to come up with any reason that this would be a bad thing, I decided it must be a good thing and that a good thing should be an issue.
    The main reason to support the OR case is that it's simply a little easier to build out the comparisonlist than the booleanexpression. And one assumes that if it's a good thing to have an ANDed ComparisonList for convenience, that it seems like symmetrically speaking it would be a good thing to have ORed ComparisonList for conveniences as well. Basically this is just a suggested small change for the convenience purposes.

  • Reported: XTCE 1.2 — Wed, 7 Feb 2024 16:02 GMT
  • Disposition: Deferred — XTCE 1.3
  • Disposition Summary:

    An OR Based Comparison List is Possible

    It is reasonable to create an "or"-based ComparisonList element optional attribute. This has a specific use case that is commonly seen where a telemetered container comes from more than one onboard computer and that computer is annotated in the header.

    At present, it has been agreed to leave this to a future revision as it for sure introduces another implementation detail that is otherwise covered by a different part of the comparison logic already within the specification.

  • Updated: Tue, 1 Jul 2025 15:04 GMT