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

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?