=== Structure of Data ===

==== Alphabetic Ordering of Types withing Groups ====
 - '''Symbolic Name in XML Configuration''': checkTypeDefOrderInGroup
 - '''Dependant Tags in XML Configuration''': -

This quality check analyzes type definitions within groups in the same module and throws a warning if type definitions within the same group are not alphabetically (or alpha-numerically, where numbers come before letters) ordered. The ordering is case-insensitive.

==== Grouping of Ports and Related Messages ====
 - '''Symbolic Name in XML Configuration''': checkPortMessageGrouping
 - '''Dependant Tags in XML Configuration''': -

This quality check verifies that port definitions are grouped together with all the message types or signatures referenced within the port definition. The ports and the message types / signatures related to them shall be grouped within the same group in the same module. Limited nested grouping is allowed, where the message / signatures may be grouped in a subgroup within the group in which the port to which they are related was defined. This can be best illustrated by examples:

[[Include(source:trunk/t3q-examples/checkPortMessageGrouping/checkPortMessageGrouping.ttcn3, text/x-rst)]]

In the above module definition, the contents of group {{{correct}}} are OK, where as the contents of group {{{incorrect}}} are not, because the message types are not defined under the same group where the port they are related to is defined. 

If a port is defined outside a group, it automatically means that the related message types cannot be defined within the same group and they are not further analyzed. If a message type is defined outside a group, it also means that it is not in the same group as the port definition it is related to. If a message type is defined within a group with the same name as the one where the port it is related to is defined, but within a different module, it is also considered a violation of the constraint and a warning will be thrown. If a message type related to a port type definition cannot be resolved, it is considered a violation of the constraint as well and an appropriate warning is thrown.

The standard (first) line numbers in the output indicate the reference point - on which lines within the port type definition has the violating message type been referenced. Additionally, next to the message type / signature name and the port type name, location triples <startLine,moduleName,groupName> are provided to facilitate the easier identification and localization of the elements violating the constraint.

Additionally, if nesting is present as in the above example, but does not violate the constraints, an information message will be provided in the output to inform the user of the occurrence.

==== No All Keyword in Port Type Definitions ====
 - '''Symbolic Name in XML Configuration''': checkNoAllKeywordInPortDefinitions
 - '''Dependant Tags in XML Configuration''': -

The check makes sure that there are no all keywords in port type definitions.