This is the main addition for GEMS 1.7 RTF.
The San Francisco RTF made progress creating the new JSON/REST PSM via the draft GEMS_1.7_RTF_REST_PSM_v6.doc, specifically the JSON encoding formats.
Continue updating the draft spec in Reston (2025 Q1) and Denver (2025 Q2).
Once done, update this ticket with a proposal containing the details.
This will be a new major section '9' in the GEMS spec, starting at page 48.

PingMessage and PingResponse appears in UML but not in Figure 6.1 nor text of Section 6.2.

GetConfigListMessage and GetConfigListResponse appears in UML but not in Figure 6.1 nor text of Section 6.2.

DisconnectMessage appears in UML and Figure 6.1 but not in text of Section 6.2.

MessageSequenceResponse appears in UML but not in Figure 6.1 nor Section 6.2, nor in either PSM

Update Figure 6.1 (GEMS Use Cases) to include missing messages, and update other sections and figures per above.

The ASCII PSM specifies that the "Message Length" field in the Standard Header is a fixed length of 10 characters, but all Example GEMS-ASCII Message Lengths are only 6 characters. So correct the Message Length of all Example GEMS-ASCII Messages in:
1) https://www.omgwiki.org/space/lib/exe/fetch.php?media=gems-1.2-examples.zip
2) https://www.omgwiki.org/space/doku.php?id=gems#gems_example_messages

During the March 23, 2022 GEMS RTF Meeting, the RTF members agreed to:
1. Add diagrams to sections 6.2.8 (Save Configuration Message), 6.2.9 (Restore Configuration Message), 6.2.11 (Asynchronous Status Message), and possibly 6.2.10 (get device definition file) for consistency with prior sections.
2. Add references from the PIM and PSM sections back to the use cases.

Add the GEMS-ASCII PSM schemas for the following:

• PingMessage
• PingResponse
• MessageSequence

It would be beneficial if an additional data type were available within GEMS of a time duration (time_duration). This allows for specification of a time offset. The suggested format would be:

[-]HH:MM:SS[.fffffffff]

Existing ground equipment solutions currently have time offsets and having this support would enable smoother and more accurate support and integration with GEMS-enabled products. Existing types do not adequately support providing an offset time duration format.

In the GEMS version 1.4 specification ASCII PSM, Table 8.6 for the "Disconnect Message Request" is missing the "Comments" column which contains certain interface details, e.g. Message Type Field = DISC.
Refer to the two attachments for the missing column in V1.4 and V1.3 which contains the column.

Section 7.5.1 states that there is an example GEMS Device Definition File on the OMG website, though Examples are not available. The example file on the Space Wiki also does not appear to include an example definition file. The website or reference should be updated.

The spec currently allows arrays, parameters sets, and arrays of parameter sets. These compound types can make for an API that's difficult to use. Specifically, if you want to modify a single member of a parameter set, you have to read it, deserialize it, modify part of it, re-serialize it, and write it back. This isn't wildly difficult, but I believe it's enough for a customer to complain about usability. This operation is particularly annoying in the case of arrays of parameter sets. Furthermore, the read/modify/write operation isn't atomic, and could result in race conditions that revert a simultaneous change.

I'd like to suggest that we extend the PIM to allow "leaf" values of compound types to be referenced directly. E.g., array elements and parameter set members could be referenced under the ASCII PSM using the following parameter names:

Array element: myArray/3
Set member: myParamSet/memberName
Array of sets: myArrayOfSets/5/memberName

...with a corresponding scheme for the XML PSM. This would require adding the forward slash as a reserved word that should not be used in parameter names, along with "|GEMS" and "|END".

During the March 23, 2022 GEMS RTF Meeting, the RTF members agreed to add text to the GEMS specification describing how GEMS Directives could be used to achieve direct leaf value access (GETs and SETs) without changing the current GEMS 1.4 interface. Mr. Luis Rodriguez offered to write this text and provide example directives.

This "Directive" approach is an alternative to the preferred approach of changing the GEMS standard to generically support direct leaf value access (e.g. via standard "dot notation") - this approach is tracked in GEMS16-1.