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.
"The issue is declared Closed.
The problem has not been fixed. It is still impossible to reference an argument in a CommandContainerSet/CommandContainer/RefEntry."
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):
The downsides are (could be more):
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?
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.
XTCE 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.
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)
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.
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.
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">
"There are eight different verifiers each associated with *difference* states in command processing"
Missing the word, "of" between "instances" and "this" in "...Interlocks apply instead to any Commands that may follow instances this MetaCommand."