1. OMG Mailing List
  2. XTCE Revision Task Force

Open Issues

  • Issues not resolved
  • Name: xtce-rtf
  • Issues Count: 36

Issues Summary

Key Issue Reported Fixed Disposition Status
XTCE13-36 RelativeTimeAgumentType is misspelled XTCE 1.2b1 open
XTCE13-35 ArgumentAssigmentList in the MetaCommandStep is misspelled XTCE 1.2b1 open
XTCE13-34 ArgumentInputSetType is inconsistent with InputSetType XTCE 1.2b1 open
XTCE13-33 Inconsistency in Argument Types with respect to FixedIntegerValueType XTCE 1.2b1 open
XTCE13-32 needs to be updated for items that no longer support hex, octal, binary XTCE 1.2b1 open
XTCE13-31 ServiceRef construction error XTCE 1.2 open
XTCE13-30 String Encoding Length descriptions needs further clean up XTCE 1.2 open
XTCE13-29 ByteOrderList is invalid for Containers XTCE 1.1 open
XTCE13-27 Cleanup Container EntryList element by deprecating IndirectParameterRefEntry XTCE 1.1 open
XTCE13-26 Re-evaluate the characterWidth attribute in String types XTCE 1.1 open
XTCE13-28 Clean up semantics of "OO-Include Condition" XTCE 1.1 open
XTCE13-24 List and List> clean up needed XTCE 1.1 open
XTCE13-25 Add event message support XTCE 1.1 open
XTCE13-23 Missing a number of changes and enumerations in ErrorDetectCorrectType children XTCE 1.1 open
XTCE13-22 Spelling error for Arguments in XTCE 1.2 proposed XTCE 1.1 open
XTCE13-21 inability to describe sets of limits (alarms) and conversions (polynomials) XTCE 1.0b1 open
XTCE13-20 lack of Union construct (MER + ASIST) XTCE 1.0b1 open
XTCE13-19 Move Alarms outside of Type Area XTCE 1.1 open
XTCE13-18 Message/IncludeCondition/BaseContainer similarity XTCE 1.1 open
XTCE13-17 Checkwindow not tied to context XTCE 1.1 open
XTCE13-16 AbsoluteTime should have Alarms XTCE 1.1 open
XTCE13-15 Add forward/reverse calibrator metadata XTCE 1.1 open
XTCE13-14 Expand NameReference semantics XTCE 1.1 open
XTCE13-13 CustomAlgorithm should be "typed" reference to AlgorithmSet XTCE 1.1 open
XTCE13-12 Add OCL specific Algorithm to XTCE XTCE 1.1 open
XTCE13-11 Should RestrictionCriteria should be assignment not operators for Commanding? XTCE 1.1 open
XTCE13-10 Re-architect XTCE alarm model XTCE 1.1 open
XTCE13-9 Need support for mask alarm XTCE 1.1 open
XTCE13-8 Add ArgumentTypeSet to MetaCommand XTCE 1.1 open
XTCE13-7 Elevate annotation specifying time string formats to an attributes XTCE 1.1 open
XTCE13-5 Add gap entry to container entry list XTCE 1.1 open
XTCE13-6 Add variable to containers XTCE 1.1 open
XTCE13-3 Add switch entry to container entry list XTCE 1.1 open
XTCE13-2 Expand features to include common industry encodings in StreamsSet XTCE 1.1 open
XTCE13-4 Provide way to categorize all elements with @name into one or more groups XTCE 1.1 open
XTCE13-1 Type inheritance missing from Absolute and Relative time data types XTCE 1.1 open

Issues Descriptions

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: Thu, 18 Oct 2018 20:04 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: Thu, 18 Oct 2018 20:04 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: Thu, 18 Oct 2018 20:03 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, 16 Oct 2018 19:38 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: Tue, 16 Oct 2018 19:38 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: Mon, 14 May 2018 17:35 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: Mon, 14 May 2018 17:31 GMT

ByteOrderList is invalid for Containers

  • Key: XTCE13-29
  • Legacy Issue Number: 14517
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Cleanup Container EntryList element by deprecating IndirectParameterRefEntry

  • Key: XTCE13-27
  • Status: open  
  • Source: Boeing ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Re-evaluate the characterWidth attribute in String types

  • Key: XTCE13-26
  • Status: open  
  • Source: Boeing ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Clean up semantics of "OO-Include Condition"

  • Key: XTCE13-28
  • Legacy Issue Number: 14509
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

List and List> clean up needed
  • Key: XTCE13-24
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT
  • Attachments:

Add event message support

  • Key: XTCE13-25
  • Legacy Issue Number: 19388
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Missing a number of changes and enumerations in ErrorDetectCorrectType children

  • Key: XTCE13-23
  • Status: open  
  • Source: Boeing ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Spelling error for Arguments in XTCE 1.2 proposed

  • Key: XTCE13-22
  • Status: open  
  • Source: Boeing ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

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

  • Key: XTCE13-21
  • Legacy Issue Number: 8908
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

lack of Union construct (MER + ASIST)

  • Key: XTCE13-20
  • Legacy Issue Number: 8909
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Move Alarms outside of Type Area

  • Key: XTCE13-19
  • Legacy Issue Number: 14454
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Message/IncludeCondition/BaseContainer similarity

  • Key: XTCE13-18
  • Legacy Issue Number: 14460
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Checkwindow not tied to context

  • Key: XTCE13-17
  • Legacy Issue Number: 14458
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

AbsoluteTime should have Alarms

  • Key: XTCE13-16
  • Legacy Issue Number: 14466
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add forward/reverse calibrator metadata

  • Key: XTCE13-15
  • Legacy Issue Number: 14473
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Expand NameReference semantics

  • Key: XTCE13-14
  • Legacy Issue Number: 14489
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

CustomAlgorithm should be "typed" reference to AlgorithmSet

  • Key: XTCE13-13
  • Legacy Issue Number: 14505
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add OCL specific Algorithm to XTCE

  • Key: XTCE13-12
  • Legacy Issue Number: 14507
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Should RestrictionCriteria should be assignment not operators for Commanding?

  • Key: XTCE13-11
  • Legacy Issue Number: 14506
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Re-architect XTCE alarm model

  • Key: XTCE13-10
  • Legacy Issue Number: 19369
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Need support for mask alarm

  • Key: XTCE13-9
  • Legacy Issue Number: 19371
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add ArgumentTypeSet to MetaCommand

  • Key: XTCE13-8
  • Legacy Issue Number: 19377
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Elevate annotation specifying time string formats to an attributes

  • Key: XTCE13-7
  • Legacy Issue Number: 19376
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add gap entry to container entry list

  • Key: XTCE13-5
  • Legacy Issue Number: 19384
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add variable to containers

  • Key: XTCE13-6
  • Legacy Issue Number: 19382
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Add switch entry to container entry list

  • Key: XTCE13-3
  • Legacy Issue Number: 19385
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Expand features to include common industry encodings in StreamsSet

  • Key: XTCE13-2
  • Legacy Issue Number: 19386
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

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

  • Key: XTCE13-4
  • Legacy Issue Number: 19381
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT

Type inheritance missing from Absolute and Relative time data types

  • Key: XTCE13-1
  • Legacy Issue Number: 19633
  • Status: open  
  • Source: NASA ( 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
  • Updated: Mon, 2 Apr 2018 18:22 GMT