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

Closed Issues

  • Issues resolved by a task force and approved by Board
  • Name: gems-rtf
  • Issues Count: 56

Issues Summary

Key Issue Reported Fixed Disposition Status
GEMS15-2 Examples GEMS 1.4 GEMS 1.5 Closed; No Change closed
GEMS15-1 Extend PIM to allow "leaf" values to be referenced directly GEMS 1.3 GEMS 1.5 Deferred closed
GEMS14-17 Extend PIM to allow "leaf" values to be referenced directly GEMS 1.3 GEMS 1.4 Deferred closed
GEMS14-24 Add read-only as a parameter attribute GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-23 "Range of Values" specified for "Message Length" is incorrect GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-22 Add 'Units' to Device Description parameter definitions GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-26 Need to remove the examples from the specification GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-25 Diagrams have lost resolution in the specification GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-15 Arrays of parameters sets not defined for ASCII PSM GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-14 HTTP header on GEMS XML example malformed GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-2 obtained only changed parameters GEMS 1.2 GEMS 1.4 Resolved closed
GEMS14-1 Need a better example for XML Get Request GEMS 1.1 GEMS 1.4 Resolved closed
GEMS14-18 Standard message trailer in ASCII PSM has extra pipe GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-20 Directives require arguments GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-19 Extra Attribute in GEMS 1.3 Directive Schema GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-4 GEMS HTTP POST example is incorrect GEMS 1.3 GEMS 1.4 Duplicate or Merged closed
GEMS14-3 GEMS Device Definition does not include a multiplicity for ParameterSetDefType GEMS 1.2 GEMS 1.4 Closed; No Change closed
GEMS14-21 DisconnectMessage doesn't have a response GEMS 1.3 GEMS 1.4 Closed; No Change closed
GEMS14-16 Mixed parameter set example has extra delimiter GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-8 Multiple issues with ASCII PSM examples GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-7 Numerous small errata and inconsistencies GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-6 Bug link URL is invalid GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-13 Arrays defined ambiguously for ASCII PSM GEMS 1.3 GEMS 1.4 Duplicate or Merged closed
GEMS14-12 SetConfigResponse defined with two parameters in PIM GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-11 Links in XML examples are broken GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-5 wrong type of quote used GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-10 Acronym not defined correctly GEMS 1.3 GEMS 1.4 Resolved closed
GEMS14-9 Figures without figure numbers GEMS 1.3 GEMS 1.4 Resolved closed
GEMS-23 The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution GEMS 1.0b1 GEMS 1.0 Resolved closed
GEMS12-6 GEMS does not define a message type for a generic malformed message GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-5 ASCII Save response has extra field in the example GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-4 No PingMessage/Response defined in XML schema GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-11 Defining arrays of ParameterSets in GEMS-XML is unclear GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-8 The comment regarding multiplicity in section 6.3.1.13 is no longer needed GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-7 Defining a zero length hex_value is ambiguous GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-10 The XML schema calls out an 'array' attribute (vs multiplicity) in the ParameterSet GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-9 There is no unambiguous way to tell if a value is a scalar or an array of one in the XML GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-2 Mapping of XML and ASCII versions is not consistent GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-1 ASCII Set Response description has a valid_state GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-3 Incorrect message types in ASCII GetConfigMessage/Response GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-14 The schema dtc/11-02-02 has 6 errors found by running an XML Schema validator GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-12 Network messages containing GEMS-XML are difficult to parse without a header containing the message length GEMS 1.1 GEMS 1.2 Resolved closed
GEMS12-13 Typos GEMS 1.1 GEMS 1.2 Resolved closed
GEMS11-5 RFP Mandatory Requirment 6.5.1.9 Not Implemented GEMS 1.0 GEMS 1.1 Resolved closed
GEMS11-3 We suggest leaving the old time type (based on POSIX) GEMS 1.0 GEMS 1.1 Resolved closed
GEMS11-2 Escape characters GEMS 1.0 GEMS 1.1 Resolved closed
GEMS11-1 Section 7.3.2.5.1 GEMS 1.0b1 GEMS 1.1 Resolved closed
GEMS11-4 Hex value arrays in ASCII GEMS 1.0 GEMS 1.1 Resolved closed
GEMS13-6 GEMS TCP socket close behavior is not obvious GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-8 Unbounded Lists In Device Definitions GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-7 Confusing comments GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-5 GEMS-XML schema (GEMS 1.2) for MessageSequenceType does not support elements for DirectiveMessage GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-4 Extend GEMS-ASCII message length GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-2 GEMS-XML ParameterSet Order GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-1 GEMS-XML hex_value length Issue GEMS 1.2 GEMS 1.3 Resolved closed
GEMS13-3 clarify GEMS authentication GEMS 1.2 GEMS 1.3 Resolved closed

Issues Descriptions

Examples

  • Key: GEMS15-2
  • Status: closed  
  • Source: Terma B.V. ( Andy Armitage)
  • Summary:

    The text says:

    7.3 XML Examples
    Examples of the GEMS XML messages are available on the OMG website at http://www.omg.org/space. Navigate to
    the GEMS specific page and look for GEMS Examples.

    I can't find any such examples! (humble apologies if they are there but I have looked)

  • Reported: GEMS 1.4 — Tue, 28 Apr 2020 16:33 GMT
  • Disposition: Closed; No Change — GEMS 1.5
  • Disposition Summary:

    GEMS examples are available

    The GEMS 1.5 Revision Task Force met today (June 24, 2020) and we agreed to close this ticket since the examples are available per the 07/May/20 comment in the original Jira ticket as follows:

    “The examples can be found by browsing to that same OMG page at https://www.omg.org/space then click on the link "GEMS™ (Ground Equipment Monitoring Service™)" which takes you to http://www.omgwiki.org/space/doku.php?id=gems that has a link to the examples at http://www.omgwiki.org/space/doku.php?id=gems_examples

  • Updated: Wed, 6 Jan 2021 15:10 GMT

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

  • Key: GEMS15-1
  • Legacy Issue Number: 19627
  • Status: closed  
  • 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
  • Disposition: Deferred — GEMS 1.5
  • Disposition Summary:

    Defer to GEMS 2.0 RFP

    The GEMS 1.5 Revision Task Force met today (June 24, 2020) and we agreed to defer this ticket to the GEMS 2.0 RFP where we can discuss it in the context of an additional PSM, i.e. JSON over REST.

  • Updated: Wed, 6 Jan 2021 15:10 GMT

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

  • Key: GEMS14-17
  • Legacy Issue Number: 19627
  • Status: closed  
  • 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
  • Disposition: Deferred — GEMS 1.4
  • Disposition Summary:

    Extend PIM to allow leaf node access

    I propose we defer this one. There are details that should be considered.

  • Updated: Tue, 28 Feb 2017 22:04 GMT

Add read-only as a parameter attribute

  • Key: GEMS14-24
  • Legacy Issue Number: 19740
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Nigel Thompson)
  • Summary:

    Some GEMS target parameters are not writable. It would be useful to know which ones are read-only when using GEMS to construct a GUI.

  • Reported: GEMS 1.3 — Wed, 8 Apr 2015 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Add readonly to the parameter definitions

    Add this as an optional attribute with a default of false for backwards compatibility.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

"Range of Values" specified for "Message Length" is incorrect

  • Key: GEMS14-23
  • Legacy Issue Number: 19739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In Table 8.2
    "Message Length" has a "Range of Values" specified as "000074-999999". We took this as the minimum possible message length to the maximum possible message length. Which, given our experience, is not true. We have encountered several instances with production hardware (Amergint & RTLogic) where the message length was fewer than 74 bytes.

    I personally don’t care if OMG decides to list a minimum length; I just want the documented "Range of Values" to reflect reality. In the case OMG doesn’t want to specify a minimum length I would suggest the range value would be listed as "000000-999999" in the spec. Listing a range of "000000" could be problematic/confusing as well, "000000" would never be a valid either... So... I will let you standards people work this one out.

  • Reported: GEMS 1.3 — Tue, 31 Mar 2015 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Range of values in the message length

    Change the range of values. Since the standard header may change, it makes sense to not specify the minimum length. That will make maintenance of the specification easier.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Add 'Units' to Device Description parameter definitions

  • Key: GEMS14-22
  • Legacy Issue Number: 19737
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Nigel Thompson)
  • Summary:

    Add 'units' as a parameter constraint (not really a constraint bu that's the section in the doc).
    Units are a string containing the unit of measurement such as mm, inch, bps

  • Reported: GEMS 1.3 — Fri, 27 Mar 2015 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Add Units to the device definition of parameters

    Add a units attribute

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Need to remove the examples from the specification

  • Key: GEMS14-26
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Currently all of the GEMS examples are in the main specification document. Since the version number is in the message header, this creates a lot of changes to the document with every update, whether the examples changed or not. To avoid this, I recommend removing the examples from the specification and references the already-existing online examples. These are non-normative, but intended to provide a robust example set.

  • Reported: GEMS 1.3 — Thu, 10 Sep 2015 16:04 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Remove the examples from the main specification

    The problem is the examples have become difficult to maintain and must be updated every revision because the version number is in the message header. We have also found minor syntax errors in the examples. To correct these, we must issue a new version of the specification, which in turn requires the examples to be updated and the message header to change.

    All of the examples will be removed from the main specification document (Sections 7.3, 7.5.1, and 8.3). The new text will provide a link to the online, non-normative examples. These examples will be maintained and updated separate from the specification.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Diagrams have lost resolution in the specification


Arrays of parameters sets not defined for ASCII PSM

  • Key: GEMS14-15
  • Legacy Issue Number: 19625
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    There is no definition for arrays of parameter sets in the ASCII PSM. Section 7.1.1.3 suggests that these are supported by the PIM, and we need a mapping for all PSMs. Currently, a single parameter set (not an array of sets) is defined with commas as the delimiter between members of the set. The comma is also used as the delimiter between array elements. This makes it very difficult to deserialize an array of parameter sets, since the same delimiter character is used for two purposes. It became even more difficult after Issue 18814 was resolved by redefining the multiplicity to be a maximum array size (with -1 as a valid value), instead of the actual array size in the message. Suggest we use semicolons as the delimiter between parameter set members, and continue using commas as the delimiter between array elements.

  • Reported: GEMS 1.3 — Tue, 30 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Define the delimiter in a parameter set to be a semi-colon

    The contents of section 8.2.1.2 have been confusing and incorrect. Specifying an array of parameter sets is undefined (clearly). We will define the delimiter to be a semi-colon with the last member of the parameter set requiring a semi-colon as well.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

HTTP header on GEMS XML example malformed

  • Key: GEMS14-14
  • Legacy Issue Number: 19622
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    The HTTP header for GEMS XML in section 7.4 has the following issues:

    1. First line contains "HTTP 1.0", which should be "HTTP/1.0"

    2. There should be an additional endline between the header and the body

  • Reported: GEMS 1.3 — Fri, 26 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    The example HTTP header is malformed

    The intent is to use the standard HTTP header for all GEMS XML messages transferred across a plain TCP socket. However, the example in the specification does not correctly show this.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

obtained only changed parameters

  • Key: GEMS14-2
  • Legacy Issue Number: 18315
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Received a request for either an asynchronous push or a new message
    type that provides changes only. This was an optional requirement in
    the original RFP

  • Reported: GEMS 1.2 — Thu, 13 Dec 2012 05:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Add AsyncStatusMessage

    This message is used for Asynchronous status messages. The transport mechanism or how it is set up are left for later versions of GEMS. At this point it was determined that the message definition would be sufficient for forward progress.

  • Updated: Tue, 29 Mar 2016 15:08 GMT
  • Attachments:

Need a better example for XML Get Request

  • Key: GEMS14-1
  • Legacy Issue Number: 15486
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Section 7.2.6.1 only provides a simple example of a GetConfigResponse with no parameters. A better example would provide parameters possibly with multiplicity so implementers have a clearer understanding of how it should be done. Replace current example with:

    <?xml version="1.0" encoding="UTF-8"?><GetConfigResponse gems_version="1.1" target="device1" timestamp="1234.98765" token="ABCD" transaction_id="1" xmlns="http://www.omg.org/gems"

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd">

    <Result>SUCCESS</Result> <description>Get config was successful</description> <Parameter name="name"> <string>Device One</string> </Parameter>

    <Parameter name="hex"> <hex_value bit_length="16">DEADBEEF</hex_value> </Parameter></GetConfigResponse>

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    GetConfigResponse Example

    The existing example in the specification is insufficient. The online example provides what is needed.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Standard message trailer in ASCII PSM has extra pipe

  • Key: GEMS14-18
  • Legacy Issue Number: 19629
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    The ASCII PSM defines the standard message trailer as "|END", but every single message type also ends with a "|" followed by "standard trailer". Strictly speaking, this results in every single message having a pair of pipes at the end with nothing between. We should remove the pipe from the standard trailer table (8.4).

  • Reported: GEMS 1.3 — Thu, 2 Oct 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Remove the extra pipe character in the message trailer

    Combining the definition of the standard message trailer with the definition of the standard messages results in an extra and unintended pipe character.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Directives require arguments

  • Key: GEMS14-20
  • Legacy Issue Number: 19661
  • Status: closed  
  • Source: ViaSat ( Dean Sniegowski)
  • Summary:

    The .xsd file requires parameters of a directive be with in <arguments> </arguments> but the example of page 37 doesn't do that.

  • Reported: GEMS 1.3 — Tue, 25 Nov 2014 05:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Directive Example

    The example in the specification was wrong and did not show the directive parameters in a containing <arguments></arguments> element.

    This issue is OBE with the removal of the examples from the specification. The online example already shows this correctly.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Extra Attribute in GEMS 1.3 Directive Schema

  • Key: GEMS14-19
  • Legacy Issue Number: 19647
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The GEMS XML schema for a directive message has an extra, optional, attribute that should not be there. This was never caught until code generation was used and the attribute showed up.

    Incorrect:

    <!--

    GEMS Directive

    -->

    <xsd:complexType name="ArgumentsType">

    <xsd:sequence>

    <xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter" type="Parameter"/>

    </xsd:sequence>

    <xsd:attribute name="directive_name" type="xsd:string" use="optional"/>

    </xsd:complexType>

    Correct:

    <!--

    GEMS Directive

    -->

    <xsd:complexType name="ArgumentsType">

    <xsd:sequence>

    <xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter" type="Parameter"/>

    </xsd:sequence>

    </xsd:complexType>

  • Reported: GEMS 1.3 — Fri, 24 Oct 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Remove the extra directive_name attribute in the Directive schema

    The directive name is specified in the DirectiveMessageType:

    <xsd:complexType name="DirectiveMessageType">
    <xsd:complexContent>
    <xsd:extension base="MessageType">
    <xsd:sequence>
    <xsd:element minOccurs="1" maxOccurs="1" name="directive_name" type="xsd:string"/>
    <xsd:element minOccurs="0" maxOccurs="1" name="arguments" type="ArgumentsType"/>
    </xsd:sequence>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

    But there is also an extra attribute in the ArgumentsType:

    <xsd:complexType name="ArgumentsType">
    <xsd:sequence>
    <xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter" type="Parameter"/>
    </xsd:sequence>
    <xsd:attribute name="directive_name" type="xsd:string" use="optional"/>
    </xsd:complexType>

    The extra attribute should be removed

  • Updated: Tue, 29 Mar 2016 15:08 GMT

GEMS HTTP POST example is incorrect

  • Key: GEMS14-4
  • Legacy Issue Number: 19513
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The example HTTP POST header is incorrectly listed in section 7.4. The first line of the header should be:

    POST /target HTTP/1.1

  • Reported: GEMS 1.3 — Thu, 10 Jul 2014 04:00 GMT
  • Disposition: Duplicate or Merged — GEMS 1.4
  • Disposition Summary:

    GEMS HTTP POST example is incorrect (Duplicate)

    This is a duplicate

  • Updated: Tue, 29 Mar 2016 15:08 GMT

GEMS Device Definition does not include a multiplicity for ParameterSetDefType

  • Key: GEMS14-3
  • Legacy Issue Number: 18813
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The ParameterSetDefType needs a multiplicity attribute similar to ParameterDefType. This allows for lists of Parameter Sets.

  • Reported: GEMS 1.2 — Mon, 15 Jul 2013 04:00 GMT
  • Disposition: Closed; No Change — GEMS 1.4
  • Disposition Summary:

    GEMS Device Definition needs multiplicity setting

    This was already fixed in GEMS 1.3

    <xsd:complexType name="ParameterSetDefType">
    <xsd:sequence>
    <xsd:element name="Description" minOccurs="0" maxOccurs="1"
    type="xsd:string" />
    <xsd:element name="ParameterDef" maxOccurs="unbounded" minOccurs="1"
    type="ParameterDefType" />
    </xsd:sequence>
    <xsd:attribute name="name" type="xsd:string" use="required" />
    <xsd:attribute name="multiplicity" type="xsd:int" use="optional" />
    </xsd:complexType>

  • Updated: Tue, 29 Mar 2016 15:08 GMT

DisconnectMessage doesn't have a response

  • Key: GEMS14-21
  • Legacy Issue Number: 19662
  • Status: closed  
  • Source: ViaSat ( Dean Sniegowski)
  • Summary:

    It would be very useful for the DisconnectMessage to have a response of success or failure.

  • Reported: GEMS 1.3 — Tue, 25 Nov 2014 05:00 GMT
  • Disposition: Closed; No Change — GEMS 1.4
  • Disposition Summary:

    DisconnectMessage Response

    The original intent of the DisconnectMessage was to allow for "good behavior". It can be sent by either the GEMS user or the GEMS device and is typically immediately followed by a socket disconnect. Therefore, the may not be an available mechanism to send the reponse (the socket is closed).

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Mixed parameter set example has extra delimiter

  • Key: GEMS14-16
  • Legacy Issue Number: 19626
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    The mixed parameter set example in 8.2.1.2 has an extra delimiter at the end of the message body:

    mixed_param_set:set_type=param_1:int=1,param_2:boolean=true,param_3:string=a short string,

    Delimiters should only be between the members of the set. This keeps them consistent with arrays (which, by the way, must NOT have delimiters at the end, since they have to be able to represent string arrays that end with an empty string element).

  • Reported: GEMS 1.3 — Tue, 30 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    The ASCII parameter set definition is incorrect

    The descriptive text in section 8.2.1.2 first shows an array (instead of a parameter set) and then incorrectly uses a comma as the delimiter.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Multiple issues with ASCII PSM examples

  • Key: GEMS14-8
  • Legacy Issue Number: 19615
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    The message examples for the ASCII PSM have the following issues. This is in addition to a handful of issue reported under Issue 19597.

    1. The hex value examples have type "hexvalue". This should be "hex_value" (with underscore).

    2. All examples have an extra space after the first pipe, e.g. "| GEMS|01|...". We should be able to use the examples literally.

    3. The SetConfigMessage example still contains the long-removed "valid state" field. The "2" should be removed from the example, i.e.
    SET-R|SUCCESS| The SET request was successful.||TRUE
    instead of
    SET-R|SUCCESS| The SET request was successful.|2|TRUE

    4. The GEMS version in all examples should be updated to the latest ("14"). Right now it's using "01".

    5. There is no ASCII example for the PING message. It should be:
    Message: |GEMS|14|000122|123|CS123|111111111.222000000|FrameSync1|PING|END
    Response: |GEMS|14|000122|123|CS123|111111111.222000000|FrameSync1|PING-R|SUCCESS|The PING request was successful.|END

  • Reported: GEMS 1.3 — Wed, 24 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Multiple issues with the GEMS-ASCII Examples

    This issue captures a number of minor syntax errors within the example provided in the specification. Almost all are a result of document formatting or our inability to keep the examples up to date. Now that the examples are removed from the specification this issue is OBE. The existing online examples correct these errors and include an example of the PING message.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Numerous small errata and inconsistencies

  • Key: GEMS14-7
  • Legacy Issue Number: 19597
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Nigel Thompson)
  • Summary:

    6.3.1.13 hex_value - Add: The length in bits is specified by following the hex data with a forward slash and the number of bits. E.g. /22.6.3.1.13 hex_value - Add: The length in bits is specified by following the hex data with a forward slash and the number of bits. E.g. /22.

    Many of the XML examples: The gems_version attribute type should be xsd:decimal not xsd:int

    Many of the XML examples: The XML examples shoudl all include the standard xml version segment like:
    <?xml version="1.0" encoding="UTF-8"?>
    This is missing from most of the examples

    Many of the examples: The gems_version is shown as an integer value like: "1". It should be shown as a decimal value like: "1.3"

    7.3.4.1 SetConfigMessage Example - this has a superfluous line: </SetConfigMessage> about half way down that needs to be deleted.

    7.3.7.1 PingMessage Example - The version number should be changed from 1.1 to 1.3

    7.3.7.2 PingResponse Example - The version number should be changed from 1.1 to 1.3

    7.3.8.1 ConnectionRequestMessage without Authentication - The version number should be changed from 1.2 to 1.3

    7.3.8.3 ConnectionRequestMessage with Authentication - The version number should be changed from 1.2 to 1.3

    7.3.8.4 Failed ConnectionRequestResponse - add the version number as 1.3

    7.3.8.5 Successful ConnectionRequestResponse - add the version number as 1.3

    7.3.8.3 ConnectionRequestMessage with Authentication - The token filed text should be: "up:john:secret"

    7.5.1 Example Device Definition File - replace 'bool' with 'boolean' 4 places

    Table 8.1 boolean type: example should be: param:boolean=true

    8.3.3 GetConfigMessage Example - change example sync_pattern to be: sync_pattern:hex_value=FAF320/22

    8.3.4 SetConfigMessage Example - change example sync_pattern to be: sync_pattern:hex_value=FAF320/22

    8.3.7 DirectiveMessage Example (response) - change accepted:bool=true to accepted:boolean=true

  • Reported: GEMS 1.3 — Wed, 10 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Clarify the bit_length field in a hex_value within the PIM

    The request was to add the /bit-length notation to the description. Since this is actually the GEMS-ASCII format (XML is different), we will add a comment about the bit_length instead.

    Issue GEMS14-7 lists many corrections in the documented examples. Since these are being removed from the document the issues are OBE. The generated examples online already correct these issues.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Bug link URL is invalid

  • Key: GEMS14-6
  • Legacy Issue Number: 19596
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Nigel Thompson)
  • Summary:

    The link on page iv for reporting bugs is an invalid page. The link should be http://www.omg.org/report_issue.htm

  • Reported: GEMS 1.3 — Wed, 10 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    The link to report issues is incorrect

    The URL for the OMG issue reporting page is incorrect. This is in a boilerplate section.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Arrays defined ambiguously for ASCII PSM

  • Key: GEMS14-13
  • Legacy Issue Number: 19620
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    Representation of arrays in the ASCII PSM is ambiguous. In 8.2.1 it says that arrays look like this:

    parameter_name[3]:type=value1,value2,value3

    The multiplicity is appended to the parameter name, there is a single type, and the values are comma separated. But in 8.2.1.2, it says arrays look like this:

    param:int[3]:int=1,int=2,int=3

    There are two colons, the multiplicity is appended to the type, and the type is repeated for each value within the comma separated list. Presumably there is a goal of unifying the way arrays and parameter sets are represented, where an array of scalars is just a homogeneous parameter set. Suggest we abandon this goal, as it will make representation of arrays of parameter sets very difficult. Suggest we represent arrays as follows:

    name:type[multiplicity]=val1,val2,val3

  • Reported: GEMS 1.3 — Wed, 24 Sep 2014 04:00 GMT
  • Disposition: Duplicate or Merged — GEMS 1.4
  • Disposition Summary:

    Arrays defined ambiguously for ASCII PSM

    This issue is basically a duplicate of GEMS14-40 and GEMS14-16. It highlights the error in array syntax and the need for a clarification on the parameter set delimiter.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

SetConfigResponse defined with two parameters in PIM

  • Key: GEMS14-12
  • Legacy Issue Number: 19619
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    Under "SetConfigResponse", it says "the message has 2 parameters", but only one parameter is described ("parameters_set"). This is probably a holdover from when the "valid state" parameter was removed back in v1.1. This should simply be changed to "the message has 1 parameter".

  • Reported: GEMS 1.3 — Wed, 24 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    SetConfigResponse descriptive text specifies the wrong # parameters

    The text indicates that here are 2 parameters, but there is only one.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Links in XML examples are broken

  • Key: GEMS14-11
  • Legacy Issue Number: 19618
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    All XML examples need to update the embedded URL. The "http://www.omg.org/gems" link is broken, it should be "http://www.omg.org/spec/GEMS" or "http://www.omg.org/spec/GEMS/current".

  • Reported: GEMS 1.3 — Wed, 24 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Links in the XML examples are broken

    Now that the examples are removed from the specification this issue is OBE. The existing online examples are generated and all include the correct link.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

wrong type of quote used

  • Key: GEMS14-5
  • Legacy Issue Number: 19563
  • Status: closed  
  • Source: ViaSat ( Dean Sniegowski)
  • Summary:

    <Parameter name=”telemetry_ports”>

    should be

    <Parameter name="telemetry_ports">

    I copy and pasted that example into a file and it took me a couple of hours to realize there was invalid quotes.

  • Reported: GEMS 1.3 — Fri, 1 Aug 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Wrong type of quote used

    The text could not be copied directly from the document because a fancy MS-Word quote had been pasted in.

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Acronym not defined correctly

  • Key: GEMS14-10
  • Legacy Issue Number: 19617
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    The SCPI acronym definition in section 4 should read "Standard Commands", not "General Command".

  • Reported: GEMS 1.3 — Wed, 24 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    SCPI Acronym not defined correctly

    The definition is wrong

  • Updated: Tue, 29 Mar 2016 15:08 GMT

Figures without figure numbers

  • Key: GEMS14-9
  • Legacy Issue Number: 19616
  • Status: closed  
  • Source: RT Logic ( Nathaniel Colson)
  • Summary:

    There are six figures in the specification that do not have figure numbers. These occur in sections 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.3.2.2, 8.2.3.

  • Reported: GEMS 1.3 — Wed, 24 Sep 2014 04:00 GMT
  • Disposition: Resolved — GEMS 1.4
  • Disposition Summary:

    Add figure captions to all diagrams

    Not all diagrams in the specification have figure captions

  • Updated: Tue, 29 Mar 2016 15:08 GMT

The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution

  • Key: GEMS-23
  • Legacy Issue Number: 13132
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    1) The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution.
    A. This new issue was raised during the FTF.
    B. Reported by David Overeem at Boeing

  • Reported: GEMS 1.0b1 — Fri, 8 Aug 2008 04:00 GMT
  • Disposition: Resolved — GEMS 1.0
  • Disposition Summary:

    Disposition: See issue 14112 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GEMS does not define a message type for a generic malformed message

  • Key: GEMS12-6
  • Legacy Issue Number: 15492
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The GEMS PIM & PSMs do not define a generic message for a response to an unreadable or completely malformed message. This can occur if the server receives a message that is either not a GEMS message (i.e. junk) or a GEMS message with a malformed header. Currently the only response messages are tied to specific message types and it is unclear what a server should return in this more general case.
    Proposed Resolution: Utilize the base response message class for this. The specific type in ASCII could be UNK-R and in XML UnknownResponse.

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Utilize the base response message class for this. Define the specific type in ASCII to be UNK-R and in XML UnknownResponse. This are simple mappings to the base response message. The response code for this message indicates the specific error and is most commonly MALFORMED_MESSAGE.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ASCII Save response has extra field in the example

  • Key: GEMS12-5
  • Legacy Issue Number: 15491
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The example for the GEMS-ASCII SaveConfigResponse in section 8.2.5 contains an extra field
    Proposed Resolution: Fix

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Remove the second numerical field (the zero).

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No PingMessage/Response defined in XML schema

  • Key: GEMS12-4
  • Legacy Issue Number: 15490
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The XML PSM sections and attached schema do not define a ping response message
    Proposed Resolution: Potential XML Ping & PingResponse messages

    <?xml version="1.0" encoding="UTF-8"?><PingMessage gems_version="1.1" target="testDevice1" timestamp="1234.98765"

    token="ABCD" transaction_id="1" xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd" />
    <?xml version="1.0" encoding="UTF-8"?><PingResponse gems_version="1.1" target="testDevice1"

    timestamp="1234.98765" token="ABCD" transaction_id="1" xmlns="http://www.omg.org/gems" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd"> <Result>SUCCESS</Result> <description>I'm Here!</description></PingResponse>

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Add a section to the PIM describing the Ping message and response. Correct the XSD and add a section to the XML PSM describing the message format.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defining arrays of ParameterSets in GEMS-XML is unclear

  • Key: GEMS12-11
  • Legacy Issue Number: 15497
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Unlike a normal Parameter with multiplicity greater than 1, a ParameterSet array contains ParameterSet elements. These each have a name and multiplicity with then that need to be ignored.
    Proposed Resolution: Add the following comment to the XSD for a ParameterSet:
    NOTE: If the multiplicity is set, then the contained ParameterSet's are entries in the
    array and the name & multiplicity (if specified) are ignored.

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    The issue here is that normally an element of an array parameter does not itself have a name or multiplicity. When translating between GEMS-XML and GEMS-ASCII there is no mapping for these. However, in GEMS-XML the XML schema allows for their existence.
    For example, a normal parameter array is defined as follows in GEMS-XML:

    <Parameter name="myarray" multiplicity="2">
    <long>1</long>
    <long>2</long>
    </Parameter>

    In contrast, a parameter set array is defined as follows in GEMS-XML:

    <ParameterSet multiplicity="2" name="setlist">
    <ParameterSet>
    <Parameter name="param1">
    <hex_value bit_length="2">0F</hex_value>
    </Parameter>
    <Parameter name="param2">
    <string>text1</string>
    </Parameter>
    </ParameterSet>
    <ParameterSet>
    <Parameter name="param1">
    <hex_value bit_length="2">1F</hex_value>
    </Parameter>
    <Parameter name="param2">
    <string>text2</string>
    </Parameter>
    </ParameterSet>
    </ParameterSet>

    Per the XML schema, it is legal to add a multiplicity and name to the internal ParameterSet elements. This is effectively an extra layer of nesting that is not required in the GEMS-ASCII version and no mapping existing for the name and multiplicity.
    To clarify the specification a comment shall be added to section 7.1.1.3 indicating that these values will be ignored.
    To further help clarify this, an additional parameter set array will be added to the SetConfigMessage example in section 7.2.4.1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The comment regarding multiplicity in section 6.3.1.13 is no longer needed

  • Key: GEMS12-8
  • Legacy Issue Number: 15494
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The way hex_value arrays are handled in GEMS 1.1 solves this problem. The comment relates to the old way of doing hex_values
    Proposed Resolution: Remove the comment

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Remove the last sentence in section 6.3.1.13: “In cases where the multiplicity is greater than one the bit_length attribute of the hex_values must all be equal.”

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defining a zero length hex_value is ambiguous

  • Key: GEMS12-7
  • Legacy Issue Number: 15493
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    There is no clear example of how to define a zero length hex_value in GEMS-ASCII. Possibilities include name:hex_value=/0 or name:hex_value=0/0
    Proposed Resolution: name:hex_value=0/0 to make parsing simpler.

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Standardize on the following format:

    name:hex_value=0/0

    This makes parsing the message easier as all valid hex_value parameters will contain content on either side of the ‘/’.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The XML schema calls out an 'array' attribute (vs multiplicity) in the ParameterSet

  • Key: GEMS12-10
  • Legacy Issue Number: 15496
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The attribute should be multiplicity to match the PIM/PSM
    Proposed Resolution: Fix

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Correct the XML schema and the text in section 7.1.1.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no unambiguous way to tell if a value is a scalar or an array of one in the XML

  • Key: GEMS12-9
  • Legacy Issue Number: 15495
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The GEMS-XML schema defines a default value for multiplicity (default of 1). The result is that parsers using the schema are unable to tell if a parameter is a scalar or an array of length one.
    Proposed Resolution: Recommend removing the default multiplicity in the xml schema and the spec should state 'no multiplicity == scalar'

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Remove the default multiplicity in the xml schema and the spec now states 'no multiplicity == scalar'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of XML and ASCII versions is not consistent

  • Key: GEMS12-2
  • Legacy Issue Number: 15488
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The mapping of XML to ASCII versions is inconsistent in the PSMs. GEMS-ASCII uses an integer (01, 02, 03...), and GEMS XML uses decimal numbers (1.1, 1.2 and so forth)
    Proposed Resolution: Need to discuss

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Add a simple mapping in table 8.2 that maps the versions. This section will be kept up to date as new GEMS versions are created.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ASCII Set Response description has a valid_state

  • Key: GEMS12-1
  • Legacy Issue Number: 15487
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The valid_state was removed from the PIM however the message table in 8.1.8.2 still has a valid state field.
    Proposed Resolution: Remove this from the table

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Remove the row in table 8.10 starting with the valid_state field name from the table.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect message types in ASCII GetConfigMessage/Response

  • Key: GEMS12-3
  • Legacy Issue Number: 15489
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The GEMS-ASCII message types are not correct in section 8.1.10.1. Appears to be a copy-n-paste error in GetConfigListMessage, GetConfigListResponse.

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Correct the comment cell in table 8.11 to use the correct message types.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The schema dtc/11-02-02 has 6 errors found by running an XML Schema validator

  • Key: GEMS12-14
  • Legacy Issue Number: 16091
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The schema dtc/11-02-02 has 6 errors found by running an XML Schema validator.

    Various types extending MessageType give the following error: derived by restriction complex type has content while base type is empty

  • Reported: GEMS 1.1 — Thu, 24 Mar 2011 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Change the restriction to an extension

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Network messages containing GEMS-XML are difficult to parse without a header containing the message length

  • Key: GEMS12-12
  • Legacy Issue Number: 15498
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Parsing a GEMS-XML message as it arrives on a TCP socket is difficult since you must first parse the stream (i.e. with SAX) and then likely validate it with a DOM.
    Proposed Resolution: Add a statement indicating that the if a transport protocol is used (e.g. smart sockets etc) that includes the length, then nothing needs to be done. Otherwise, if TCP sockets are used, a HTTP header is pre-pended.

  • Reported: GEMS 1.1 — Thu, 2 Sep 2010 04:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Add a statement indicating that if a transport protocol is used (e.g. smart sockets etc) that includes the length, then nothing needs to be done. Otherwise, if TCP sockets are used, a HTTP header is pre-pended.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos

  • Key: GEMS12-13
  • Legacy Issue Number: 16017
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    6.3.1.4: but – bit
    6.3.2: update supported versions (1 becomes 1.0, 1.1 and 1.2)
    6.5: 3rd sentence, change 'contents' to 'content' (there is only one token field, so I think this is the better fix)
    7.1.1.1: in the Unsigned Short Integer, change fixed="time" to fixed="ushort". (the XML schema is correct.. just a typo in the document)
    8.1.2: first sentence after the escape sequence table, change 'chosed' to 'chosen'

  • Reported: GEMS 1.1 — Fri, 11 Feb 2011 05:00 GMT
  • Disposition: Resolved — GEMS 1.2
  • Disposition Summary:

    Fix errors (see revised text)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RFP Mandatory Requirment 6.5.1.9 Not Implemented

  • Key: GEMS11-5
  • Legacy Issue Number: 14850
  • Status: closed  
  • Source: Boeing ( Mr. David Overeem)
  • Summary:

    The device definition return that is specified in the original RFP at section 6.5.1.9 does not appear to be implemented in the released specification 1.0.

  • Reported: GEMS 1.0 — Wed, 9 Dec 2009 05:00 GMT
  • Disposition: Resolved — GEMS 1.1
  • Disposition Summary:

    Add a GEMS Device Definition description to the PIM. This description is generic in nature and defers the specifics of the description to the PSMs.
    Define the exact format of the GEMS Device Definition in the GEMS-XML PSM as an XML file. This file may be obtained manually (e.g. distributed directly by the GEMS vendor) or automatically by serving the file out through an HTTP GET using the following URL: http://hostname/omg/gems/DeviceDefinitions.xml

  • Updated: Fri, 6 Mar 2015 20:58 GMT

We suggest leaving the old time type (based on POSIX)

  • Key: GEMS11-3
  • Legacy Issue Number: 14112
  • Status: closed  
  • Source: Amergint Technologies ( Mr. Luis Rodriguez)
  • Summary:

    UTC Time as a new type Create a new time type that uses the UTC time format. This would allow for times that are human readable and that also support leap seconds. Unfortunately the current time type cannot be replaced because the XML schema for it wouldn't easily support this new format for time. We suggest leaving the old time type (based on POSIX) which we admit is useful under many circumstances.

  • Reported: GEMS 1.0 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — GEMS 1.1
  • Disposition Summary:

    Adopt utime as a new parameter type. Updates are to be made in the PIM and PSMs. This resolution allows for backward compatibility with GEMS 1.0 since existing implementations will not utilize utime parameter types.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Escape characters

  • Key: GEMS11-2
  • Legacy Issue Number: 14111
  • Status: closed  
  • Source: Amergint Technologies ( Mr. Luis Rodriguez)
  • Summary:

    Escape characters: To make parsing quite a bit easier (enabling the use of string tokenizer tools found in most modern programming languages) we suggest changing the current escape character implementation with a mechanism similar to the one used for HTML / XML. This would mean identifying all special characters ('|', ',', ';' . . .) and creating character sequences for them ('&p', '&c', . . .). Doing this would simplify parsing code significantly. The initial message could then be easily split using the '|' as the token. Array members could easily be split using a ',' etc...

  • Reported: GEMS 1.0 — Sat, 11 Jul 2009 04:00 GMT
  • Disposition: Resolved — GEMS 1.1
  • Disposition Summary:

    Adopt a simple escape character sequence. There are numerous standard escape sequences available, but the most common do not provide for the specific four characters needed in the GEMS ASCII PSM: | , & ;
    To keep the ASCII PSM simple the following table is to be used:
    Character Escape Sequence
    & &a

    &b
    , &c
    ; &s

    Other PSMs might need a different escape sequence and will define this table differently.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.2.5.1

  • Key: GEMS11-1
  • Legacy Issue Number: 12755
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Need to describe what a GET message returns when targeted to a proxy. There is no description of what is returned when a GetMessage is sent to a proxy.
    Options:

    • Return information on the proxy such as an array of target names available ''behind'' the proxy.
    • Return all parameters for all devices behind the proxy
    • Defined standard parameters for the proxy which would then be returned
  • Reported: GEMS 1.0b1 — Fri, 8 Aug 2008 04:00 GMT
  • Disposition: Resolved — GEMS 1.1
  • Disposition Summary:

    Return a parameter with the name 'targets' that provides an array of strings, each array value represents a single target.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Hex value arrays in ASCII

  • Key: GEMS11-4
  • Legacy Issue Number: 14113
  • Status: closed  
  • Source: Amergint Technologies ( Mr. Luis Rodriguez)
  • Summary:

    Hex value arrays in ASCII This was already differed as an issue during the FTF to be fixed later. Some additional feedback received was to use a format like 'FAF320/20' instead of notation like 'FAF320.20'. The later matches the notation used for the current time type but might cause too much confusion with floats.

  • Reported: GEMS 1.0 — Mon, 27 Jul 2009 04:00 GMT
  • Disposition: Resolved — GEMS 1.1
  • Disposition Summary:

    Adopt the FAF320/20 format.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GEMS TCP socket close behavior is not obvious

  • Key: GEMS13-6
  • Legacy Issue Number: 18723
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    GEMS VERSION 1.2

    It is not obvious what happens to a client using either GEMS-ASCII or GEMS-XML across TCP when the TCP socket is closed. If the client has successfully connected to a GEMS Device, is that GEMS connection (and resulting token) still active or does it automatically disconnect? Section 6.5 indicates that it should be disconnected, but this is not an obvious place for this behavior to be described.

    Also, GEMS-XML states that the HTTP header should be added. When using client-side HTTP libraries, the default behavior is to disconnect often. This is an internet-style approach. The GEMS specification should state that persistent socket connection are required

  • Reported: GEMS 1.2 — Thu, 16 May 2013 04:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Clarify socket behavior for GEMS over a TCP connection by stating that once a TCP connection is lost, the GEMS device should disconnect

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unbounded Lists In Device Definitions

  • Key: GEMS13-8
  • Legacy Issue Number: 18814
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    It is not clear how to define the multiplicity of a list of Parameters or ParameterSets when the list is unbounded or can vary in length. For example, if the multiplicity is set to 5, it is assumed this means the list must contain 5 parameters. How does one specify "up to 5" or "unbounded"?

  • Reported: GEMS 1.2 — Mon, 15 Jul 2013 04:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Create standard method of declaring unbounded list sizes. Use a multiplicity of -1 to indicate an unbounded array, while a non-negative and non-zero multiplicity indicates that the array may contain up to the number. For example, a multiplicity of 5 indicates that the array may contain anywhere between 0 and 5 elements.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Confusing comments

  • Key: GEMS13-7
  • Legacy Issue Number: 18733
  • Status: closed  
  • Source: us.af.mil ( Michael Heffron)
  • Summary:

    The comments about the GEMS Version field in Table 8.2 are confusing. Is the example trying to imply that starting with GEMS version 1.2 the GEMS Version field digits matches the actual GEMS version number, or what?

  • Reported: GEMS 1.2 — Fri, 24 May 2013 04:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Clarify comment text to specify that starting after version 1.2, the GEMS version field will be the same as the GEMS version number, with the decimal point removed (1.2 is 12, 1.3 is 13, etc.)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GEMS-XML schema (GEMS 1.2) for MessageSequenceType does not support elements for DirectiveMessage

  • Key: GEMS13-5
  • Legacy Issue Number: 18535
  • Status: closed  
  • Source: Anonymous
  • Summary:

    GEMS-XML schema (GEMS 1.2) for MessageSequenceType does not support elements for DirectiveMessage, even though DirectiveMessageType shares the same base (MessageType) as the other supported elements defined in MessageSequenceType.

  • Reported: GEMS 1.2 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Add DirectiveMessages to the MessageSequenceType in the GEMS-XML schema. Upon analysis of this issue, it was discovered the several other message types were missing. These were not reported in the original issue, but are fixed as part of the resolution.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extend GEMS-ASCII message length

  • Key: GEMS13-4
  • Legacy Issue Number: 18314
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Currently the message length is limited to 999999 characters. This can
    cause problems translating from GEMS-XML to GEMS-ASCII. It also limits
    the utility of message sets

  • Reported: GEMS 1.2 — Thu, 13 Dec 2012 05:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Extend message length to 10 characters

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GEMS-XML ParameterSet Order

  • Key: GEMS13-2
  • Legacy Issue Number: 16952
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The current GEMS-XML schema requires that Parameters and ParameterSets are always listed in that order. (i.e. ParameterSets cannot precede Parameters). It seems that these should be order independent.

    Reported to AMERGINT by Raytheon

  • Reported: GEMS 1.2 — Tue, 10 Jan 2012 05:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Fix the schema to be order independent.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GEMS-XML hex_value length Issue

  • Key: GEMS13-1
  • Legacy Issue Number: 16950
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    The GEMS-XML XSD bases the HexParameter on the xsd:hexBinary type. This type expects an even number of characters (two for each octet). The GEMS-XML specification should mention this and explain how it needs to be handled.

    Recommend always providing an even number of hex characters and using the bit length to specify the actual length.

    Example of an invalid 4 bit field: E/4

    Example of a valid 4 bit field: E0/4

  • Reported: GEMS 1.2 — Tue, 10 Jan 2012 05:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Pad the hex_value field to two full nibbles for the XML.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

clarify GEMS authentication

  • Key: GEMS13-3
  • Legacy Issue Number: 18313
  • Status: closed  
  • Source: Amergint Technologies ( Rob Andzik)
  • Summary:

    Authentication of a GEMS user is loosely defined in the specification.
    This should be clarified and include a better definition of how
    credentials are passed in, what is the roll (if any) of SSL and
    similar transports, and how do proxies handle authentication. In
    particular, how does a GEMS user grab control of a system without
    creating a race condition.

  • Reported: GEMS 1.2 — Thu, 13 Dec 2012 05:00 GMT
  • Disposition: Resolved — GEMS 1.3
  • Disposition Summary:

    Add a multiplicity attribute to the ParameterSetDefType declaration to the GEMS_Device file, where it was omitted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT