The terms XTCE and GEMS should not be part of the SOLM meta models or functions that are projected from it (like SpacePython).

The specification should talk about Parameters that are being queried (possibly as Spacecraft or Ground Parameters), though the transport/method should be decoupled since there are multiple interfaces that could be used (direct integration with an end product, via GEMS, via SNMP, via a message bus/C2MS, or perhaps via a database).

... While doing this we think we’ve identified an omission in the mapping table.

If you look at the SOLM you’ll see this model for the Parameter. Note the highlighted aggregate object. If we go to the table for the mapping we see:

Parameter.value()
Parameter.raw()

Of course raw() doesn’t exist in the model, but there’s a description (note uncal doesn’t exist). But the but is there’s no mapping item to get the timestamp. However in the reference implementation in a section that should be normative there’s the report method that returns the time and the value (effectively a tuple that represents the InstantValue – see the 6.4.6 description).

In my book this should be a bug report to add a Parameter.report() that returns the InstantValue data as a tuple of value, timestamp. So can we report this as a bug?

SpacePython is not compatible with Python version 3. Multiple script errors are encountered. Python version 2 is no longer supported, so software should be updated to work with later version.

The comments in SetMomentumWheelSpeed.py state that the <module>._doc_ text corresponds to the Procedure.description attribute in the metamodel. This text should correspond the HeaderComment in the metamodel instead, and the Procedure.description should correspond to <module>.invoke._doc_