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 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
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
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.
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
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
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.
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
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?
The ParameterSetDefType needs a multiplicity attribute similar to ParameterDefType. This allows for lists of Parameter Sets.
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"?