1. OMG Mailing List
  2. GEMS 1.6 Revision Task Force mailing list

Open Issues

  • Issues not resolved
  • Name: gems-rtf
  • Issues Count: 2

Issues Descriptions

Collection of items found in V1.4 specification

  • Key: GEMS16-2
  • Status: open  
  • Source: Northrop Grumman Space Systems ( Stuart Austin)
  • Summary:

    1. No GEMS PSM Reference Designs are available. There is no way to independently assess a PSM implementation's conformance against the PSM or PIM.
    2. Issues with Device Definition file
    2.1 Section 7.5.1 says there is an example Device Definition file in the Examples directory on the OMG web site. This is not true.
    2.2 Section 6.2.10 "Obtain Device Information" appears to describe how a user retrieves the capabilities of the GEMS device - that is, it appears to define the Device Definition file and how to retrieve it. However there are no messages defined for the sequence in this paragraph nor any other.
    2.3 Section 6.2.10 also describes the capabilities as "descriptions of the directives (including argument name and type information) and the parameters (including name, type and range information). This therefore does not describe any of the other messages supported by the Device.
    2.4 That information is reiterated in Section 6.9, "Device Definitions" - it appears that only "parameters and directives supported by a GEMS Device" are included. Therefore should one assume that "parameters" means those attributes of a device controlled by SetConfigMessage?
    2.5 No definition of the Device Definition file in the GEMS UML
    2.6 No definition of the Device Definition file in the GEMS-ASCII PSM
    3. UML message classes with no Use Cases defined:
    3.1 PingMessage and PingResponse (appears in UML but not in Figure 6.1 nor text of Section 6.2)
    3.2 GetConfigListMessage andGetConfigListResponse (appears in UML but not in Figure 6.1 nor text of Section 6.2)
    3.3 DisconnectMessage (appears in UML and Figure 6.1 but not in text of Section 6.2)
    3.4 MessageSequenceResponse (appears in UML but not in Figure 6.1 nor Section 6.2, nor in either PSM)
    4. There are mismatches between the PIM specification and each of the XML and ASCII PSMs
    4.1 AsyncStatusMessage is not specified in the XML PSM schema.
    4.2 The following appear in XML PSM schema but not in the Spec nor ASCII PSM
    4.2.1 UnknownResponse
    4.3 No GEMS-ASCII PSM specification for
    4.3.1 DisconnectMessage
    4.3.2 PingMessage
    4.3.3 PingResponse
    4.3.4 MessageSequence, MessageSequenceResponse
    4.4 No definition of the Device Definition file in the GEMS-ASCII PSM
    4.5 No formal grammar for ParameterSet in GEMS-ASCII PSM, just "may be defined by the additional use of semi-colons".
    4.6 Specification of utime incomplete or incorrect
    5. Limitations on the GEMS specification are stated in Section 6.2.13 of that document. These specification limitations include that it:
    5.1 Does not specify exact parameters, types and ranges for any specific Device or Device type
    5.2 Proposes a Standard Devices package that would contain definitions of these standard devices, parameters and directives, but makes no attempt to define this package
    5.3 Proposes a Custom Devices package that allows Device vendors to provide the specification of their PIM in a PSM-compliant fashion, but makes no attempt to define this package
    6. version field of the GEMS message class only supports up to 1.2 though 1.4 is the current spec
    7. Sections, and have the wrong heading level - should not be headings at all, but rather, paragraphs under
    8. Likewise, sections 6.4.1 and 6.4.2 do not need to be headings, but rather, paragraphs under 6.4
    9. Section 6.5 typo "messages are structure as" vs "messages are structured as"
    10. Section 8 should be "PSM (ASCII)" not "PIM (ASCII)"
    11. Table 8.2 should include the "type" (per Table 8.1) of each field
    12. Table 8.2, row "Transaction ID" column "Comments" - formatting error. The extra line break character after the word "message" makes the last word ("correlation") wrap outside the table cell boundary and therefore difficult to find
    13. ASCII PSM issues:
    13.1 specifies that the message begins with the delimiter but doesn't end with the same delimiter
    13.2 time parameter shown in Table 8.1 appears to indicate 9 places for seconds, decimal, 9 places for nanoseconds; however any contemporary UTC time needs 10 places for seconds (see examples from GEMS web site)
    12.3 Table 8.3 refers to non-existent "Standard Header Table 9.2"
    12.4 Length field in message is fixed-length at 10 ASCII characters but all examples show this as 6 ASCII characters
    12.5 Description of Response message does not include a final delimiter before END marker; all examples show two delimiters between return code and END

  • Reported: GEMS 1.5 — Mon, 3 May 2021 17:46 GMT
  • Updated: Tue, 4 May 2021 14:49 GMT

Extend PIM to allow "leaf" values to be referenced directly

  • Key: GEMS16-1
  • Legacy Issue Number: 19627
  • Status: open  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

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

  • Reported: GEMS 1.3 — Tue, 30 Sep 2014 04:00 GMT
  • Updated: Tue, 10 Nov 2020 14:34 GMT