XML Telemetric & Command Exchange Format Avatar
  1. OMG Specification

XML Telemetric & Command Exchange Format — Open Issues

  • Acronym: XTCE
  • Issues Count: 23
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE13-107 Revert change to CalibratorType base type XTCE 1.2 open
XTCE13-30 String Encoding Length descriptions needs further clean up XTCE 1.2 open
XTCE13-67 CustomAlarmType has wrong parent XTCE 1.2 open
XTCE13-39 Inconsistent time unit data types XTCE 1.2 open
XTCE13-34 ArgumentInputSetType is inconsistent with InputSetType XTCE 1.2b1 open
XTCE13-37 Incorrect MetaCommandRef element definition XTCE 1.2 open
XTCE13-72 CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer XTCE 1.2 open
XTCE13-65 lost annotation in 1.2 inputAlgorithmType schema type rework XTCE 1.2 open
XTCE13-71 CNES CCSDS -- unit set "form" question XTCE 1.2 open
XTCE13-33 Inconsistency in Argument Types with respect to FixedIntegerValueType XTCE 1.2b1 open
XTCE13-31 ServiceRef construction error XTCE 1.2 open
XTCE13-91 MemberType and ComparisonType annotation misses fix to value formatting XTCE 1.2 open
XTCE13-70 CNES CCSDS -- inside/outside range support in ValidRange XTCE 1.2 open
XTCE13-68 CNES CCSDS -- Time ParameterType inheritance may need to be repolled XTCE 1.2 open
XTCE13-36 RelativeTimeAgumentType is misspelled XTCE 1.2b1 open
XTCE13-69 CNES CCSDS -- RelativeTimeAgument typo XTCE 1.2 open
XTCE13-35 ArgumentAssigmentList in the MetaCommandStep is misspelled XTCE 1.2b1 open
XTCE13-66 Unecessary Sequence of choice in AlarmType XTCE 1.2 open
XTCE13-74 Is rangeForm specialization needed for Change and Multi band alarms? XTCE 1.2 open
XTCE13-73 rangeForm annotation needs work XTCE 1.2 open
XTCE13-40 Duplicated BaseCalibratorType extension XTCE 1.2 open
XTCE13-38 Missing default value of dataSource attribute XTCE 1.2 open
XTCE13-32 needs to be updated for items that no longer support hex, octal, binary XTCE 1.2b1 open

Issues Descriptions

Revert change to CalibratorType base type

  • Key: XTCE13-107
  • Status: open  
  • Source: Northrop Grumman ( 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
  • Updated: Thu, 2 Apr 2020 14:16 GMT

String Encoding Length descriptions needs further clean up

  • Key: XTCE13-30
  • Status: open  
  • Source: NASA ( 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
  • Updated: Fri, 8 Nov 2019 17:43 GMT

CustomAlarmType has wrong parent

  • Key: XTCE13-67
  • Status: open  
  • Source: NASA ( 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
  • Updated: Fri, 8 Nov 2019 16:57 GMT

Inconsistent time unit data types

  • Key: XTCE13-39
  • Status: open  
  • Source: Northrop Grumman ( 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
  • Updated: Fri, 8 Nov 2019 15:55 GMT

ArgumentInputSetType is inconsistent with InputSetType

  • Key: XTCE13-34
  • Status: open  
  • 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
  • Updated: Fri, 8 Nov 2019 14:07 GMT

Incorrect MetaCommandRef element definition

  • Key: XTCE13-37
  • Status: open  
  • Source: Northrop Grumman ( 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
  • Updated: Thu, 7 Nov 2019 13:36 GMT

CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer

  • Key: XTCE13-72
  • Status: open  
  • Source: NASA ( 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
  • Updated: Thu, 7 Nov 2019 12:55 GMT

lost annotation in 1.2 inputAlgorithmType schema type rework

  • Key: XTCE13-65
  • Status: open  
  • Source: NASA ( 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
  • Updated: Wed, 6 Nov 2019 12:23 GMT

CNES CCSDS -- unit set "form" question

  • Key: XTCE13-71
  • Status: open  
  • Source: NASA ( 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
  • Updated: Wed, 6 Nov 2019 12:17 GMT

Inconsistency in Argument Types with respect to FixedIntegerValueType

  • Key: XTCE13-33
  • Status: open  
  • 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
  • Updated: Tue, 5 Nov 2019 12:02 GMT

ServiceRef construction error

  • Key: XTCE13-31
  • Status: open  
  • Source: NASA ( 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
  • Updated: Fri, 25 Oct 2019 00:57 GMT

MemberType and ComparisonType annotation misses fix to value formatting

  • Key: XTCE13-91
  • Status: open  
  • Source: Boeing ( 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
  • Updated: Fri, 25 Oct 2019 00:57 GMT

CNES CCSDS -- inside/outside range support in ValidRange

  • Key: XTCE13-70
  • Status: open  
  • Source: NASA ( 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
  • Updated: Fri, 25 Oct 2019 00:57 GMT

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

  • Key: XTCE13-68
  • Status: open  
  • Source: NASA ( 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
  • Updated: Fri, 25 Oct 2019 00:57 GMT

RelativeTimeAgumentType is misspelled

  • Key: XTCE13-36
  • Status: open  
  • 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
  • Updated: Tue, 15 Oct 2019 00:00 GMT

CNES CCSDS -- RelativeTimeAgument typo

  • Key: XTCE13-69
  • Status: open  
  • Source: NASA ( 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
  • Updated: Tue, 15 Oct 2019 00:00 GMT

ArgumentAssigmentList in the MetaCommandStep is misspelled

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

    This should be ArgumentAssignmentList, with an "n".

  • Reported: XTCE 1.2b1 — Thu, 18 Oct 2018 17:03 GMT
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Unecessary Sequence of choice in AlarmType

  • Key: XTCE13-66
  • Status: open  
  • Source: NASA ( 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
  • Updated: Tue, 15 Oct 2019 00:00 GMT

Is rangeForm specialization needed for Change and Multi band alarms?

  • Key: XTCE13-74
  • Status: open  
  • Source: NASA ( 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
  • Updated: Wed, 9 Oct 2019 10:51 GMT

rangeForm annotation needs work

  • Key: XTCE13-73
  • Status: open  
  • Source: NASA ( 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
  • Updated: Wed, 9 Oct 2019 10:47 GMT

Duplicated BaseCalibratorType extension

  • Key: XTCE13-40
  • Status: open  
  • Source: Northrop Grumman ( 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
  • Updated: Tue, 20 Aug 2019 00:03 GMT

Missing default value of dataSource attribute

  • Key: XTCE13-38
  • Status: open  
  • Source: Northrop Grumman ( 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
  • Updated: Wed, 12 Jun 2019 00:17 GMT

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

  • Key: XTCE13-32
  • Status: open  
  • 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
  • Updated: Wed, 12 Jun 2019 00:17 GMT