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.