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.

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.

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

Remove the second numerical field (the zero).

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>

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.

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.

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.

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

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

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.

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 ‘/’.

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

Correct the XML schema and the text in section 7.1.1.3

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'

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

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

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.

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

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

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.

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

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

Change the restriction to an extension

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.

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.

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'

Fix errors (see revised text)