Update AlarmType Annotation

• Key: XTCE14-46
• Status: open  
• Source: Boeing ( Mr. David Overeem)
• Summary:

  After examination:

  I believe you are correct in that somewhere in all the refactoring, someone missed (completely) updating the annotation on AlarmType. I will add an issue against it for you and we will correct it in the 1.4 release sometime in the next year or two, depending on if there is anything else pressing.

  Original Note:

  subject: REQUEST INFORMATION

  textarea: Hi! I'm working with the XTCE 1.3 standard and I noticed a discrepancy in the schema. I wasn't sure how to reach out to let y'all know about this small issue.

  In the schema definition for "AlarmType", the documentation mentions, amongst others, the following XTCE types: CustomAlgorithmType, BinaryAlarmConditionType, and TimeAlarmConditionType. None of those three types actually exist in the schema (although, the others mentioned in that documentation block do exist).

  Let me know if there's another channel I should use for this in the future or if you need any additional information from me.

  Thanks!

• Reported: XTCE 1.3 — Fri, 30 Jan 2026 17:28 GMT
• Updated: Fri, 30 Jan 2026 17:28 GMT

lost annotation in 1.2 inputAlgorithmType schema type rework

• Key: XTCE14-22
• Status: open  
• 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
• Updated: Wed, 10 Dec 2025 22:30 GMT

AbsoluteTime should have Alarms

• Key: XTCE14-12
• Legacy Issue Number: 14466
• Status: open  
• 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
• Updated: Wed, 10 Dec 2025 22:28 GMT

CNES CCSDS -- Want ArgumentEntryRef in CommandContainerSet/CommandContainer

• Key: XTCE14-23
• Status: open  
• 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
• Updated: Wed, 10 Dec 2025 22:23 GMT

Add ArgumentTypeSet to MetaCommand

• Key: XTCE14-5
• Legacy Issue Number: 19377
• Status: open  
• 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
• Updated: Wed, 10 Dec 2025 22:21 GMT

FixedValueEntry, maybe it's not as good as it could be

• Key: XTCE14-28
• Status: open  
• 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
• Updated: Wed, 10 Dec 2025 22:16 GMT

Add an optional attribute to ComparisonList to make it all ORs

• Key: XTCE14-29
• Status: open  
• 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
• Updated: Wed, 10 Dec 2025 22:14 GMT

List