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_

Change text within SetMomentumWheelSpeed.py

Change the text comment within SetMomentumWheelSpeed.py.

The SpacePython files should point to the copyright information within the SOLM specification itself rather than a single vendor.

Change copyright in files

Change the copyright to be based on the Object Management Group's SOLM specification

Within space/parameters.py, the ulong (an unsigned type) is mapped to an int (a signed type). Should be mapped to unsigned (an unsigned format).

Change ulong mapping to be "unsigned"

Within the typeNames assignment of space/parameters.py, change int to unsigned in:
'uint': unsigned, 'long': int, 'ulong': int,\

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.

Update reference of Python 2.6 and deliver Python3 version of SpacePython files

Within spec document, update references of Python 2.6 to Python 3.

Apply changes to Python files to incorporate changes to make it work under Python3. These changes were performed using Git and a patch file is provided of the changes.

... 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?

Defer to future minor revision version

Defer to future revision.

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).

Defer to future minor revision version

Defer implementation until future revision

The title of the spec as well as the introduction of it (section 1.1...) make the reader think that this spec is about all known and future spacecrafts while it's about Earth Satellites as proved by, e.g., the use of UTC time.
The introduciton needs clearly to state this and the name of the spec should be changed - earth Satellite Operations Language Metamodel (eSOLM)? -.

Rename Spacecraft Operations Language Metamodel to Satellite Operations
Language Metamodel. Occurrences corrected on Title page, document footer,
and Glossary (p 4).
On page 1 introduction replace first paragraph:
This specification defines a meta-model, Spacecraft Operations Language Meta-model (SOLM), for
representing spacecraft operations procedures. These procedures contain sequences of instructions to
conduct spacecraft operations, typically consisting of spacecraft commands and spacecraft telemetry
comparisons. These procedures may also include the configuration of ground equipment, configuration of
spacecraft test equipment, execution of ground testing, and execution of on-orbit testing. Historically, these
procedures have been captured in flowcharts, text manuals, and a number of different scripting languages
used for ground station automation. A standard meta-model to represent spacecraft operations procedures
will facilitate the transfer of procedures between the spacecraft vendor and the spacecraft operator, as well
as allow for maintenance and transfer of the procedures across different ground systems employed over the
lifetime of the spacecraft.
With:
This specification defines a meta-model, Satellite Operations Language Meta-model (SOLM), for
representing spacecraft operations procedures. These procedures contain sequences of instructions to
conduct spacecraft operations, typically consisting of spacecraft commands and spacecraft telemetry
comparisons. These procedures may also include the configuration of ground equipment, configuration of
spacecraft test equipment, execution of ground testing, and execution of on-orbit testing. Historically, these
procedures have been captured in flowcharts, text manuals, and a number of different scripting languages
used for ground station automation. A standard meta-model to represent spacecraft operations procedures
will facilitate the transfer of procedures between the spacecraft vendor and the spacecraft operator, as well
as allow for maintenance and transfer of the procedures across different ground systems employed over the
lifetime of the spacecraft.
This specification is primarily aimed at providing procedure portability for earth-orbiting satellites. While
deep-space spacecraft use similar operational procedures, they also use extensive on-board procedures and
there are significant considerations in the representation of time that are not incorporated in this metamodel.

The SpacePython mapping is too vague to insure compatible implementations, and the example python script in the document will not cut-and-paste as a valid script. Please provide all example scripts as machine-consumable files and expand the SpacePython example to cover all of the SOLM features or add additional examples to cover the features

Added two additional SpacePython script examples to cover the Python extensions required by
SOLM. Created an installable Python package that contains the script examples and enough
skeleton implementation to run the scripts on any Python-compatible platform. Also created a
package with the equivalent CCL scripts in machine-consumable form. Regress the Python
version compatibility requirement to 2.6 to allow working with current enterprise Linux releases.

Model should be exported in latest available XMI (2.4.1 is current)

The original XMI file in the specification was exported in XMI 1.4 from the model in Enterprise
Architect. This file is replaced with a current export after all other modeling changes have been
applied.

Procedure.duration is typed by an unknown tyoe - RelativeTime. Reset this type to TimeInterval

This resolution applies to the non-normative model as captured in Enterprise Architect and results
in changes to the normative XMI model when it is exported. The “revised text” below shows the
impact on the XMI model.

The classifier - Time - for WaitOnExpression.timeout and WaitOnTime.time were not set correctly (usually if the classifier is typed into the field)..

This resolution applies to the non-normative model as captured in Enterprise Architect and results
in changes to the normative XMI model when it is exported. The “revised text” below shows the
impact on the XMI model. Figures 5 and 6 are generated from the non-normative model and
required updating for consistent use of the TimeInterval and SpecificTime classifiers. A document
search also found that section 6 contained two references to an older non-existent classifier
name (RelativeTime) instead of the TimeInterval classifier in the normative metamodel.

SpecificTime.dayOfYear() returns a void - change to Integer per the other methods

This resolution applies to the non-normative model as captured in Enterprise Architect and results
in changes to the normative XMI model when it is exported. The “revised text” below illustrates
the impact on the XMI model. There is also a change in Figure 11 for the method signature.

The model makes use of a 'UML' Code product type - if you set the Language for each class to '<none>' you not only get the same PrimitiveTypes, but the XMI exporter will produce the correct hrefs in the XMI to those DataTypes defined in UML

This resolution applies to the language selection in the non-normative model as
captured in Enterprise Architect and results in changes to the normative XMI
model when it is exported. The “revised text” below illustrates the impact on the
XMI model, but does not identify every line changed, since the XMI is machine
generated.