Ground Equipment Monitoring Service Avatar
  1. OMG Specification

Ground Equipment Monitoring Service — Closed Issues

  • Acronym: GEMS
  • Issues Count: 14
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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

Issues Descriptions

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