Issues for Mailing list of the GEMS 1.3 revision task Force
To comment on any of these issues, send email to gems-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 12755: Section 7.3.2.5.1
Issue 13132: The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution
Issue 14111: Escape characters
Issue 14112: We suggest leaving the old time type (based on POSIX)
Issue 14113: Hex value arrays in ASCII
Issue 14850: RFP Mandatory Requirment 6.5.1.9 Not Implemented
Issue 15487: ASCII Set Response description has a valid_state
Issue 15488: Mapping of XML and ASCII versions is not consistent
Issue 15489: Incorrect message types in ASCII GetConfigMessage/Response
Issue 15490: No PingMessage/Response defined in XML schema
Issue 15491: ASCII Save response has extra field in the example
Issue 15492: GEMS does not define a message type for a generic malformed message
Issue 15493: Defining a zero length hex_value is ambiguous
Issue 15494: The comment regarding multiplicity in section 6.3.1.13 is no longer needed
Issue 15495: There is no unambiguous way to tell if a value is a scalar or an array of one in the XML
Issue 15496: The XML schema calls out an 'array' attribute (vs multiplicity) in the ParameterSet
Issue 15497: Defining arrays of ParameterSets in GEMS-XML is unclear
Issue 15498: Network messages containing GEMS-XML are difficult to parse without a header containing the message length
Issue 16017: Typos
Issue 16091: The schema dtc/11-02-02 has 6 errors found by running an XML Schema validator
Issue 16950: GEMS-XML hex_value length Issue
Issue 16952: GEMS-XML ParameterSet Order
Issue 18313: clarify GEMS authentication
Issue 18314: Extend GEMS-ASCII message length
Issue 18315: obtained only changed parameters
Issue 18535: GEMS-XML schema (GEMS 1.2) for MessageSequenceType does not support elements for DirectiveMessage
Issue 18723: GEMS TCP socket close behavior is not obvious
Issue 18733: Confusing comments
Issue 18813: GEMS Device Definition does not include a multiplicity for ParameterSetDefType
Issue 18814: Unbounded Lists In Device Definitions
Issue 12755: Section 7.3.2.5.1 (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution: Return a parameter with the name 'targets' that provides an array of strings, each array value represents a single target.
Revised Text: Add the following paragraph to the end of section 6.2.11.1: A GEMS proxy is considered to be a device and can be the target of messages such as the SetConfigMessage and GetConfigMessage. The specifics of any proxy parameters, directives or other behavior is left to the implementor to define. At a minimum, in the event a GetConfigMessage is sent to a proxy, the resulting GetConfigResponse will contain at least one parameter named 'targets'. That parameter is a string array listing all of the target names handled by that specific proxy instance.
Actions taken:
August 8, 2008: received issue
April 26, 2010: closed issue
Discussion: It is suggested that this be deferred to the RTF.
Disposition: Deferred
Issue 13132: The time format is closer to POSIX than UTC and does not allow for unambiguous leap second resolution (gems-rtf)
Click here for this issue's archive.
Source: Boeing (Mr. David Overeem, david.t.overeem(at)boeing.com)
Nature: Uncategorized Issue
Severity:
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
Resolution: Disposition: See issue 14112 for disposition
Revised Text:
Actions taken:
August 8, 2008: received issue
December 2, 2008: received issue
April 30, 2009: closed issue
Discussion: It is suggested that this be deferred to a future RTF.
Issue 14111: Escape characters (gems-rtf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
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...
Resolution: 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.
Revised Text: Replace section 8.1.2 with the following text: The following words are reserved and should not be used as parameter or target names:
"|GEMS" and "|END|"
The following characters are special but can be escaped using the following escape sequences:
Character Escape Sequence
& &a
| &b
, &c
; &s
These escape sequences were chosen for the ASCII PSM to allow for simple parsing. Notionally, implementations first tokenize on a vertical bar '|' character. Then, for messages containing parameters, split the parameter fields on the first equal sign '='. Escaped characters should only show up to the right of the equal sign in string parameters.
Actions taken:
July 11, 2009: received issue
July 27, 2009: received issue
April 26, 2010: closed issue
April 26, 2010: closed issue
Issue 14112: We suggest leaving the old time type (based on POSIX) (gems-rtf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
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.
Resolution: 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.
Revised Text: see pages 5 through 7 of dtc/2009-12-01 for details
Actions taken:
July 27, 2009: received issue
April 26, 2010: closed issue
Issue 14113: Hex value arrays in ASCII (gems-rtf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
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.
Resolution: Adopt the FAF320/20 format.
Revised Text: hange the hex_value row in table 8.1 to:hex_value param:hex_value=faf320/22param:hex_value=0xfaf320/22 Bit length attribute in parenthesis Change the Message example in 8.2.7 to: |GEMS|01|000122|123|CS123|111111111.222000000|FrameSync1|DIR|sendVehicleCommand|1|command:hex_value=FF1234567890ABCDFF/63|END
Actions taken:
July 27, 2009: received issue
April 26, 2010: closed issue
Issue 14850: RFP Mandatory Requirment 6.5.1.9 Not Implemented (gems-rtf)
Click here for this issue's archive.
Source: Boeing (Mr. David Overeem, david.t.overeem(at)boeing.com)
Nature: Revision
Severity: Significant
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.
Resolution: 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
Revised Text: Change the first sentence of the paragraph following Figure 6.2 from:
Typically, the device vendor defines and maintains the associated GEMS device definitions.
To
Typically, the device vendor defines and maintains the associated GEMS device definitions. The device definitions are either distributed manually by the vendor (e.g. incorporated in to product documentation or as a GEMS Device Definition file), or directly from the GEMS device as an electronic document. See section 6.8 for more information on Device Definitions
Add a new section, 6.8, with the following content:
6.8 Device Definitions
A GEMS Device may optionally provide a GEMS Device Definition to clients. The intent of the device definition is to describe the parameters and directives supported by a GEMS Device, including textual descriptions and any constraints, in a machine-readable format. The format, and mechanism for obtaining the information, is PSM specific. A GEMS Device Definition may contain more than one device if a logical grouping of devices exists within the system.
The GEMS Device Definition contains the following information:
A list of one or more devices, each containing:
• Device Target Name
• List of Parameter Definitions or Parameter Set Definitions
• List of Directive Definitions
The Device Target Name is the target name used in all GEMS messages when referencing the device.
6.8.1 Parameter Definitions
Parameter definitions are used to define an individual parameter on a GEMS device. Parameter Definitions contain the following:
• Parameter Name
• Parameter Type
• Description of the parameter (free text)
• A list of constraints, if any, restricting values of the parameter
Parameter constraints may contain one or more of the following:
• maximum/minimum/fixed length (applies to strings)
• pattern as a regular expression (applies to strings)
• enumerated list of values (applies to strings)
• inclusive maximum/minimum values (applies to numeric and time values)
• exclusive maximum/minimum values (applies to numeric and time values)
• maximum/minimum number of nano seconds (applies to time values)
6.8.2 Parameter Set Definitions
Parameter Set definitions contain the following:
• Name
• Description of the parameter set (free text)
• List of Parameter Definitions as defined in 6.8.1
6.8.3 Directive Definitions
Directive definitions are used to define the directives supported by a GEMS Device. Parameter Definitions are used to define the arguments and return values of the directive.
Each Directive Definition includes the following:
• Directive Name
• Description of the directive (free text)
• A list of arguments (represented as a list of Parameter or Parameter Set Definitions)
• A list of return values (represented as a list of Parameter or Parameter Set Definitions)
Add a new section, 7.4, with the following
7.4 GEMS Device Definitions
The GEMS-XML mapping of a Device Definition takes the form of an XML file. The schema for this file is defined in the normative GEMS_Device.xsd file, included as part of the GEMS-XML PSM. To avoid redundancy between documents, comments have been added in the schema file, describing the various portions of the schema.
The XML Device Definition file is either distributed manually by the device vendor as part of the system delivery, or automatically using an HTTP GET request. It is expected that the HTTP GET request is handled using standard HTTP protocols on port 80. However, alternate port number may be specified by the vendor.
If provided automatically using an HTTP GET request, the URL for the device definition file shall be as follows:
http://<hostname>/omg/gems/DeviceDefinitions.xml
where <hostname> is either the hostname or a valid IP address for the web server on the device.
7.4.1 Example Device Definition File
The following XML provides a non-normative example of the GEMS-XML Device Definition File.
<?xml version="1.0" encoding="UTF-8"?>
<GemsDeviceDefinition gems_version="1.2"
xmlns="http://www.omg.org/gems"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.omg.org/gems GEMS_Device.xsd">
<Device target="x/y/z">
<Description />
<Parameters>
<!-- Generic String max length 24. No min-->
<ParameterDef name="mystring" type="string">
<Description />
<Restriction>
<minLength value="0" />
<maxLength value="24" />
</Restriction>
</ParameterDef>
<!-- Boolean Parameter -->
<ParameterDef name="mybool" type="bool">
<Description />
</ParameterDef>
<!-- Byte Parameter with a series of valid ranges -->
<ParameterDef name="mybyte" type="byte">
<Description />
<Restriction>
<minInclusive value="-3" />
<maxInclusive value="-1" />
</Restriction>
<Restriction>
<minInclusive value="0" />
<maxInclusive value="127" />
</Restriction>
</ParameterDef>
<!-- Unsigned Byte Parameter -->
<ParameterDef name="myubyte" type="ubyte">
<Description />
<Restriction>
<minInclusive value="0" />
<maxInclusive value="256" />
</Restriction>
</ParameterDef>
<!-- Unsigned Byte Parameter -->
<ParameterDef name="myubyte" type="ubyte">
<Description />
<Restriction>
<minInclusive value="0" />
<maxInclusive value="256" />
</Restriction>
</ParameterDef>
<!-- Hex Parameter -->
<ParameterDef name="myhex" type="hex_value">
<Description />
<Restriction>
<minLength value="0" />
<maxLength value="24" />
</Restriction>
</ParameterDef>
<!-- Double Parameter with this format 1234.56789123 -->
<ParameterDef name="mydouble" type="double">
<Description />
<Restriction>
<minInclusive value="0.1" />
<maxInclusive value="256.345699" />
</Restriction>
</ParameterDef>
<!-- Long Parameter -->
<ParameterDef name="mylong" type="long">
<Description />
<Restriction>
<minInclusive value="-2147483647" />
<maxInclusive value="2147483647" />
</Restriction>
</ParameterDef>
<!-- Unsigned Long Parameter -->
<ParameterDef name="myulong" type="ulong">
<Description />
<Restriction>
<minInclusive value="0" />
<maxInclusive value="4294967295" />
</Restriction>
</ParameterDef>
<!-- Integer Parameter -->
<ParameterDef name="myint" type="int">
<Description />
<Restriction>
<minInclusive value="-2147483647" />
<maxInclusive value="2147483647" />
</Restriction>
</ParameterDef>
<!-- Unsigned Integer Parameter -->
<ParameterDef name="myint" type="uint">
<Description />
<Restriction>
<minInclusive value="0" />
<maxInclusive value="4294967295" />
</Restriction>
</ParameterDef>
<!-- Short Parameter -->
<ParameterDef name="myshort" type="short">
<Description />
<Restriction>
<minInclusive value="-32767" />
<maxInclusive value="32767" />
</Restriction>
</ParameterDef>
<!-- Unsigned Short Parameter -->
<ParameterDef name="myshort" type="ushort">
<Description />
<Restriction>
<minInclusive value="0" />
<maxInclusive value="65535" />
</Restriction>
</ParameterDef>
<!-- Time Parameter -->
<ParameterDef name="mytime" type="time">
<Description />
</ParameterDef>
<!-- UTC Time Parameter -->
<ParameterDef name="myutime" type="utime">
<Description />
</ParameterDef>
<!-- Boolean Array Parameter -->
<ParameterDef name="myboolarray" type="bool"
multiplicity="10">
<Description />
</ParameterDef>
<!-- Enumerated String -->
<ParameterDef name="myenum" type="string">
<Description />
<Restriction>
<enumeration value="ENUM_A" />
<enumeration value="ENUM_B" />
<enumeration value="ENUM_C" />
</Restriction>
</ParameterDef>
<ParameterSetDef name="mystruct">
<Description />
<!-- UTC Time Parameter -->
<ParameterDef name="myutime" type="utime">
<Description />
</ParameterDef>
<!-- Boolean Array Parameter -->
<ParameterDef name="myboolarray" type="bool"
multiplicity="10">
<Description />
</ParameterDef>
<!-- Enumerated String -->
<ParameterDef name="myenum" type="string">
<Description />
<Restriction>
<enumeration value="ENUM_A" />
<enumeration value="ENUM_B" />
<enumeration value="ENUM_C" />
</Restriction>
</ParameterDef>
</ParameterSetDef>
</Parameters>
<Directives>
<DirectiveDef name="mydirective">
<Arguments>
<!-- String Argument -->
<ParameterDef name="arg1name" type="string">
<Description />
<Restriction>
<minLength value="0" />
<maxLength value="24" />
</Restriction>
</ParameterDef>
<!-- Boolean Argument -->
<ParameterDef name="arg2name" type="bool">
<Description />
</ParameterDef>
</Arguments>
<ReturnValues>
<!-- Integer return -->
<ParameterDef name="return1name" type="int">
<Description />
<Restriction>
<minInclusive value="-2147483647" />
<maxInclusive value="2147483647" />
</Restriction>
</ParameterDef>
<!-- Hex Parameter -->
<ParameterDef name="return2name" type="hex_value">
<Description />
<Restriction>
<minLength value="0" />
<maxLength value="24" />
</Restriction>
</ParameterDef>
</ReturnValues>
</DirectiveDef>
</Directives>
</Device>
</GemsDeviceDefinition>
Add a new section, 8.4, with the following content:
8.4 GEMS Device Definitions
The GEMS-ASCII Device Definitions utilize the GEMS-XML Device Definition file as specified in section 7.4. This file may be distributed manually by the device vendor or by using a locally hosted web server and an HTTP GET message similar to GEMS-XML.
Actions taken:
December 9, 2009: received issue
July 11, 2011: closed issue
Issue 15487: ASCII Set Response description has a valid_state (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution: Remove the row in table 8.10 starting with the valid_state field name from the table.
Revised Text:
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15488: Mapping of XML and ASCII versions is not consistent (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution: 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.
Revised Text: Modify the comments cell in the GEMS Version row of table 8.2 by changing:
Message Format Version
To:
Message Format Version Mapping
01 : 1.0
02 : 1.1
12 : 1.2
13 : 1.3 (etc.)
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15489: Incorrect message types in ASCII GetConfigMessage/Response (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: Correct the comment cell in table 8.11 to use the correct message types.
Revised Text: Change the comment cell in the ‘Standard Header’ row of table 8.11 from:
Message Type Field = SAVE or LOAD
To:
Message Type Field = GETL
Change the comment cell in the ‘Standard Header’ row of table 8.12 from:
Message Type Field = DIR-R
To:
Message Type Field = GETL-R
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15490: No PingMessage/Response defined in XML schema (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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>
Resolution: 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.
Revised Text: Add Section 6.3.3.9 with the following content:
6.3.3.9 Ping Message And Response
The ping message provides a simple mechanism for determining if the GEMS device is still responding to messages. The use of this message is optional. The response to the message is a Ping Response.
Insert a new Section 7.1.1.25 with the following content:
The GEMS-XML mapping for the PingMessage is as follows:
<xsd:complexType name="PingMessageType">
<xsd:complexContent>
<xsd:extension base="MessageType">
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="PingMessage" type="PingMessageType"/>
Insert Section 7.1.1.26 with the following content:
The GEMS-XML mapping for the PingResponseMessage is as follows:
<!—Define a PingResponse -->
<xsd:complexType name="PingResponseType">
<xsd:complexContent>
<xsd:extension base="ResponseMessageType"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="PingResponse" type="PingResponseType"/>
Add Section 7.2.7 with the following content:
7.2.7 Ping Message/Response
The following is an example of the PingMessage and PingResponse
7.2.7.1 PingMessage Example
<?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" />
7.2.7.2 PingResponse Example
<?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>
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15491: ASCII Save response has extra field in the example (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary: The example for the GEMS-ASCII SaveConfigResponse in section 8.2.5 contains an extra field
Proposed Resolution: Fix
Resolution: Remove the second numerical field (the zero).
Revised Text: Replace the SaveConfigMessage response example in section 8.2.5 with:
|GEMS|01|000122|123|CS123|111111111.222000000|FrameSync1|SAVE-R|SUCCESS|The SAVE request was successful.|100|END
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15492: GEMS does not define a message type for a generic malformed message (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: Split the first paragraph in section 6.3.2.2 in to two paragraphs and change to the following:
All GEMS response messages contain a result code and an optional free-text description. The result code indicates the success of failure of the original message. If a failure occurs, the specific result code can be inspected programmatically and the appropriate action taken. In the event an unrecognizable message is received, a generic base response message is returned with the result code set to indicate the error. Most commonly the result code for this type of error is MALFORMED_MESSAGE.
The acceptable result codes are as follows:
Insert a paragraph and XML content at the end of section 7.1.1.14 that includes the following:
The GEMS-XML mapping for a generic error response message is as follows:
<xsd:element name="UnknownResponse" type="ResponseMessageType"/>
Insert a new paragraph at the end of section 8.1.3 containing:
The GEMS-ASCII mapping for a generic error response message is simply a standard response header and trailer with the message type set to UNK-R.
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15493: Defining a zero length hex_value is ambiguous (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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 ‘/’.
Revised Text: Replace the existing comment associated with the hex_value type in table 8.1 with the following:
The value of the bit length attribute follows the slash (/). Specify a zero length bit field with a 0/0.
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15494: The comment regarding multiplicity in section 6.3.1.13 is no longer needed (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution: 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.”
Revised Text: Section 6.3.1.13 should now read:
Represents an ASCII representation of a hexadecimal value. The string may optionally be preceded by a ‘0x’.
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15495: There is no unambiguous way to tell if a value is a scalar or an array of one in the XML (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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'
Resolution: Remove the default multiplicity in the xml schema and the spec now states 'no multiplicity == scalar'.
Revised Text: Section 7.1.1.2:
Add the following sentences to the initial paragraph:
The multiplicity attribute is used only if the parameter is an array. The multiplicity then specifies the number of items in the array. If no multiplicity attribute is specified, the parameter is a scalar.
Change the second to last line in the XML schema text from:
<xsd:attribute name="multiplicity" type="xsd:int" default="1"/>
to:
<xsd:attribute name="multiplicity" type="xsd:int" use=”optional”/>
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15496: The XML schema calls out an 'array' attribute (vs multiplicity) in the ParameterSet (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary: The attribute should be multiplicity to match the PIM/PSM
Proposed Resolution: Fix
Resolution: Correct the XML schema and the text in section 7.1.1.3
Revised Text: In section 7.1.1.3:
Replace the second to last line in the XML schema text from:
<xsd:attribute name="array" type="xsd:boolean" default=”false”/>
To:
<xsd:attribute name="multiplicity" type="xsd:int" use=”optional”/>
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 15497: Defining arrays of ParameterSets in GEMS-XML is unclear (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: In Section 7.1.1.3 add the following paragraph as the second paragraph in that section:
If the multiplicity is set, indicating an array of ParameterSets, then the contained ParameterSet elements are entries in the array. The name and multiplicity attributes (if specified) are ignored. This is to ensure a consistent mapping with the equivalent GEMS-ASCII message.
In Section 7.2.4.1, insert the following XML just before the </SetConfigMessage> line:
<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>
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Discussion:
Issue 15498: Network messages containing GEMS-XML are difficult to parse without a header containing the message length (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: Modify the text in Section 7.3 from:
Transfer of GEMS-XML messages across a network transport such as TCP/IP is done by simply writing the GEMS- XML message directly to the socket.
To (includes text through the example):
Transfer of GEMS-XML messages across a network transport is done by writing the XML directly to the transport layer. If the transport layer includes the message length, the XML text is all that is required. This is the case with several commercially available message oriented middleware solutions. However, if the message length is not included, as is the case with normal TCP/IP sockets, then a standard HTTP header and the standard XML encoding pseudo-attribute is added to the message. This is done to simplify processing of the message on the other side.
The HTTP header format is as follows:
POST /target HTTP 1.0
User-Agent: OMG-GEMS
Content-Type: text/xml
Content-Length: length of the included GEMS-XML request in bytes
The Content-Length specifies the number of bytes to read after the HTML header and includes any formatting characters (spaces, end-of-line etc.)
Example:
POST /target HTTP 1.0
User-Agent: OMG-GEMS
Content-Type: text/xml
Content-Length: 324
<?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" />
Actions taken:
September 2, 2010: received issue
July 11, 2011: closed issue
Issue 16017: Typos (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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'
Resolution: Fix errors (see revised text)
Revised Text: Section 6.3.1.4: change the word but to bit.
Section 6.3.2.1: Section titled ‘version’, change:
The version field contains the version of GEMS message being used. It provides backwards compatibility. Currently only version 1 is supported.
To
The version field contains the version of GEMS message being used. It provides backwards compatibility. Currently only version 1.0, 1.1 and 1.2 are supported.
Section 6.5: 3rd sentence, change 'contents' to 'content'
Section 7.1.1.1: in the Unsigned Short Integer, change fixed="time" to fixed="ushort".
Section 8.1.2: first sentence after the escape sequence table, change 'chosed' to 'chosen'
Actions taken:
February 11, 2011: received issue
July 11, 2011: closed issue
Issue 16091: The schema dtc/11-02-02 has 6 errors found by running an XML Schema validator (gems-rtf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
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
Resolution: Change the restriction to an extension
Revised Text: The following is the diff between versions.
===================================================================
--- GEMS_base_types.xsd (revision 12061)
+++ GEMS_base_types.xsd (working copy)
@@ -1,6 +1,6 @@
<?xml version='1.0' encoding='windows-1252'?>
-<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.omg.org/gems" xmlns="http://www.omg.org/gems" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
+<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.omg.org/spec/gems/20110323/basetypes" xmlns="http://www.omg.org/spec/gems/20110323/basetypes" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<!-- GEMS Parameter Type Definitions -->
@@ -190,7 +190,7 @@
-->
<xsd:complexType name="MessageSequenceType">
<xsd:complexContent>
- <xsd:restriction base="MessageType">
+ <xsd:extension base="MessageType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="SetConfigMessage" type="SetConfigMessageType"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="GetConfigMessage" type="GetConfigMessageType"/>
@@ -200,7 +200,7 @@
<xsd:element maxOccurs="unbounded" minOccurs="0" name="LoadConfigResponse" type="LoadConfigResponseType"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="SaveConfigResponse" type="SaveConfigResponseType"/>
</xsd:sequence>
- </xsd:restriction>
+ </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
@@ -235,12 +235,12 @@
-->
<xsd:complexType name="ResponseMessageType">
<xsd:complexContent>
- <xsd:restriction base="MessageType">
+ <xsd:extension base="MessageType">
<xsd:sequence>
<xsd:element minOccurs="1" maxOccurs="1" name="Result" type="ResultCode"/>
<xsd:element minOccurs="0" maxOccurs="1" name="description" type="xsd:string"/>
</xsd:sequence>
- </xsd:restriction>
+ </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
@@ -277,12 +277,12 @@
-->
<xsd:complexType name="SetConfigMessageType">
<xsd:complexContent>
- <xsd:restriction base="MessageType">
+ <xsd:extension base="MessageType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter" type="Parameter"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="ParameterSet" type="ParameterSet"/>
</xsd:sequence>
- </xsd:restriction>
+ </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
@@ -309,12 +309,12 @@
-->
<xsd:complexType name="GetConfigMessageType">
<xsd:complexContent>
- <xsd:restriction base="MessageType">
+ <xsd:extension base="MessageType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="Parameter" type="Parameter"/>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="ParameterSet" type="ParameterSet"/>
</xsd:sequence>
- </xsd:restriction>
+ </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
@@ -373,11 +373,11 @@
-->
<xsd:complexType name="LoadConfigMessageType">
<xsd:complexContent>
- <xsd:restriction base="MessageType">
+ <xsd:extension base="MessageType">
<xsd:sequence>
<xsd:element name="name" type="StringParameter"/>
</xsd:sequence>
- </xsd:restriction>
+ </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
@@ -513,12 +513,12 @@
<xsd:complexType name="DirectiveMessageType">
<xsd:complexContent>
- <xsd:restriction base="MessageType">
+ <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:restriction>
+ </xsd:extension>
</xsd:complexContent>
</xsd:complexType>
The following changes apply to the specification document:
Replace all instances of
xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd"
with
xsi:schemaLocation="http://www.omg.org/spec/gems/20110323/basetypes GEMS_base_types.xsd"
In section 7.2 (including changes made due to other issues in this RTF)
Replace all instances of
xmlns=”http://www.omg.org/gems”
with
xmlns="http://www.omg.org/spec/gems/20110323/basetypes"
In section 7.4.1 (new as of this RTF)
Replace
xmlns=”http://www.omg.org/gems”
with
xmlns=”http://www.omg.org/spec/gems/20110323/device”
In section 7.4.1
Replace all instances of
xsi:schemaLocation=”http://www.omg.org/gems GEMS_Device.xsd”
with
xsi:scemaLocation=”http://www.omg.org/spec/gems/20110323/device GEMS_Device.xsd”
Actions taken:
March 24, 2011: received issue
July 11, 2011: closed issue
Issue 16950: GEMS-XML hex_value length Issue (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution:
Revised Text:
Actions taken:
January 10, 2012: received issue
Issue 16952: GEMS-XML ParameterSet Order (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution:
Revised Text:
Actions taken:
January 10, 2012: received issue
Issue 18313: clarify GEMS authentication (gems-rtf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution:
Revised Text:
Actions taken:
December 13, 2012: received issue
Issue 18314: Extend GEMS-ASCII message length (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution:
Revised Text:
Actions taken:
December 13, 2012: received issue
Issue 18315: obtained only changed parameters (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution:
Revised Text:
Actions taken:
December 13, 2012: received issue
Issue 18535: GEMS-XML schema (GEMS 1.2) for MessageSequenceType does not support elements for DirectiveMessage (gems-rtf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
Resolution:
Revised Text:
Actions taken:
March 7, 2013: received issue
Issue 18723: GEMS TCP socket close behavior is not obvious (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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
Resolution:
Revised Text:
Actions taken:
May 16, 2013: received issue
Issue 18733: Confusing comments (gems-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
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?
Resolution:
Revised Text:
Actions taken:
May 24, 2013: received issue
Issue 18813: GEMS Device Definition does not include a multiplicity for ParameterSetDefType (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
Summary: The ParameterSetDefType needs a multiplicity attribute similar to ParameterDefType. This allows for lists of Parameter Sets.
Resolution:
Revised Text:
Actions taken:
July 15, 2013: received issue
Issue 18814: Unbounded Lists In Device Definitions (gems-rtf)
Click here for this issue's archive.
Source: Amergint Technologies (Mr. Rob Andzik, andzik(at)amergint.com)
Nature: Uncategorized Issue
Severity:
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"?
Resolution:
Revised Text:
Actions taken:
July 15, 2013: received issue