Several small edits were not included in previous updates.

Make small edits detailed in revised section.

See small changes in the revised section.

SpecificTime class should support providing a timezone and the waitUntil() function should support timezones that have a timezone.

Update SpacePython to support timezone being specified in SpecificTime class

SpecificTime should allow providing time strings that have a timezone.
waitUntil() function should respect the timezone of the field provided.
waitUntil() is also being updated to work with SpecificTime or the underlying timedate type.

Line 49: Change to:
t = datetime.datetime.now(tz)

Line 51: Change to:
t.second, t.microsecond, tz)

Line 56 (added after Line 55):
May optionally end with a timezone indicator, such as Z.

Lines 62-68 replaced with:
t = datetime.datetime.fromisoformat(strval)

Line 70 replaced with:
t.second, t.microsecond, t.tzinfo)

Line 186 replaced with:
def waitUntil(specificTime:datetime.datetime) -> None: #Normative

Line 192 replaced with:

1. use same timezone for now as the provided datetime
   now = SpecificTime.now(specificTime.tzinfo)

Complete changes are in the attached patch file against the changes as a result of SOLM12-6.

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

Replace with sample() function

Replace SpacePython report() function with a new function sample() that returns a dictionary including the time, value, and raw values for a single sample. The change for this function is included in the work for issue #6.

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

Addressing references to the PSM of SpacePython at this time

The updated section of SpacePython (section 8) is being replaced with new content as part of issue #6. The updated version addresses this issue for the single PSM that remains as part of SOLM.

The user interface (operatorQuery) function is embedded in the middle of the SpacePython implementation and is not able to be separately implemented.

The method of prompting for a value may vary (such as for a web user interface versus a desktop application) and this variance is independence of the implementing provider for the SOLM language module.

Implementing as part of changes to issue #6

Issue #6 includes updates to the SpacePython library to allow for a pluggable interface for different implementations of the language. The plug-in can have different implementations for the UI and data backing.

SpacePython 1.1 requires that the reference implementation is modified/tailored by an implementing project/customer. As such, it does not have a loosely coupled implementation where the interface and implementation are separate.

Implementing as part of changes to issue #6

Issue #6 includes updates to the SpacePython library to allow for a pluggable interface for different implementations of the language.

The data model should harmonize spacecraft and ground assets and therefore the language model should simplify/make this consistent as much as possible.

Update to align with modern language

See changes in the Revised Text.

Patch file for this change is attached to this issue.

Within SpacePython times.py TimeInterval _str_() function, the following lines are faulty:

hours = seconds / 3600
minutes = (seconds % 3600) / 60

Both of these variables should be integers (not floating point values)

These instead should be:
hours = int(seconds / 3600)
minutes = int((seconds % 3600) / 60)

Update hours and minutes calculations

In times.py, change:
hours = seconds / 3600
To:
hours = int(seconds / 3600)

And:
minutes = (seconds % 3600) / 60
To:
minutes = int((seconds % 3600) / 60)

Section 6.7 represents compliance between the SOLM spec and the original RFP requirements. This likely should have been part of section 0 and removed during FTF. As such, this section should now be removed.

Remove section 6.7

Remove 6.7 in its entirety.

The Comet Control Language is a vendor-specific language that is not maintained by the SOLM RTF or any active member of the Space Domain Task Force. As such, it is unable to be maintained by the SOLM RTF maintainers. In addition, we do not see value in maintaining it due to lack of awareness of it being implemented/used in conjunction with SOLM.

Remove mentions of Comet Control Language

See Revised Text

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that allow determining the current status/flags of a parameter (including the severity) are not available in the language at this time.

Defer to future SpacePython version

Defer to future SpacePython version. Can be re-evaluated in the future.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that enabling the establishment and release of command locks are missing from the language.

Defer to future SpacePython version

Defer to future SpacePython version. Can be re-evaluated in the future.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that perform telemetry and limit checks are missing from the language at this time.

Defer to future SpacePython version

Defer to future SpacePython version. Can be re-evaluated in the future.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that allow retrieval of metadata from a previous directive/command that was issued do not exist in the language.

Defer to future SpacePython version

Defer to future SpacePython version. Can be re-evaluated in the future.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that create ground system events do not currently exist in the language.

Defer to future SpacePython version

Defer to future SpacePython version. Can be re-evaluated in the future.

SpacePython is missing critical functions to be able to perform vital capability required for a real-time command and control system.

Functions that provide parameter and type information are lacking or insufficient in the language.

Defer to future SpacePython version

Can be re-evaulated in the future

operatorQuery allows for any number of inputs of any type to be provided. An implementation is very difficult to provide a friendly experience.

Would be valuable if guidance is provided for common usage patterns, including:

• Yes/No prompt
• Confirmation prompt (Message Box)
• Pick from a list (enum/dropdown/picklist)
• Input string, number, arrays
• Considerations for rich dialogs
• Password/credential prompts

Defer to future SpacePython version

Existing OperatorQuery function only supports string parameter input (for zero or more strings). Consider extending the Query class to have additional methods for other usage patterns in the future.

SpacePython defines its own time object. It should instead utilize native time/date functionality. This would make procedures be easier to author and better integrate with existing and third-party libraries.

Native Python DateTime class does not support nanoseconds

The current custom class adds support for nanoseconds. It is an extended class on top of the native type though.

Deferring this issue to re-evaluate if Python gains improved time precision.