627   SCL cannot be used to represent message structure

This tissue has following status: green

Proposer: Greg LaMarre , GE Energy

Page: 74

Clause: 9.5.1

Paragraph: 3

Category: Issue for edition 2 of this part

Issue: Clause 9.5.1 states that "The order of DO elements within an LNodeType definition, and of SDO/DA elements within a DOType definition shall also specify the order of data values within a message, if this is not specified elsewhere, for example by explicit FCDA definitions in a data set down to the attribute."

The spirit of this statement suggests that a client should be able to use the SCL to establish parsing rules for a message reported by the server. However, other parts of the standard do not prevent IED vendors from defining extended data attribute names with an initial upper case letter. Such IED vendors have been certified. Such names are not compliant with the SCL and so must be left out of the SCL. If these data attributes are not included in the SCL, then a client that uses the SCL to establish parsing rules will not be able to parse messages from such devices.

So if my understanding of the intention of SCL to represent the message structure is correct, then there appears to be a loophole here that allows an interoperability issue between clients that use the SCL to establish parsing rules and servers that extend the model with data attribute names that don't begin with a lower case letter. In actuality, this is a real world interoperability issue that is happening between vendors today.

Proposal: Make it clear that the SCL is not intended to be used by clients for establishing the parsing rules for messages, or update other parts of the standard (e.g. 8-1) stating that extended data attributes added in the MMS model must begin with a lower case character.