IBM
Contents Index Previous Next



The Restrictions in the TTCN Suite


The TTCN Suite editing tools support TTCN and ASN.1 as defined in the TTCN standard. The TTCN To C compiler on the other hand has limitations on its ASN.1 coverage. See TTCN ASN.1 BER Encoding/Decoding for further details on the restrictions that apply. In a few other cases, the TTCN Suite has introduced syntactical restrictions, but in all such cases there are simple work-around solutions.

This section describes the modifications in the TTCN and ASN.1 grammar, e.g. the differences between the TTCN/ASN.1 standards and the language supported by the TTCN Suite. Modifications meaning that some constructs will not be analyzed correctly even though they have legal syntax according to the TTCN/ASN.1 standards.

External ASN.1 Types

The analysis of an ASN.1 Value requires access to its Type. In TTCN it is possible to refer to an external ASN.1 Type and define an ASN.1 Value of that type.

Therefore an extra field is included in the ASN.1 type by reference tables. The user provides the definition of an external ASN.1 type in this field. The allowed syntax/semantic for this field is the same as for regular ASN.1 type definition. ASN.1 values of such a reference type will be analyzed according to the provided type definition.

The extra field is exported if the option IBM Rational MP format is chosen. It is, though, not printed together with the ASN.1 type by reference table.

Another solution to this problem is to open the referred ASN.1 module in the Organizer and define an dependencies link to it (see Dependencies for more information). The type definition is fetched from the referred ASN.1 module before it is analyzed. For more information, see ASN.1 External Type/Value References.

ValueList

The problem is that a ValueList constraint (in MatchingSymbol) with only one element has the same construction as a parenthesized Expression in the top level. In addition, a ConstraintValue and an Expression may appear in the same places (since Expression is allowed in the ConstraintValue).

The Analyzer assumes that a ValueList with only one element is a parenthesized Expression wherever it appears.

Example 308

Assuming the Test Suite Constant C1 (of type integer) with value (2 - X), C2 (also of type integer) with value 3 * (M - K) and C3 (also of type integer) with value (3, X). Both C1 and C2 are correct both syntactically and semantically, but C3 has an illegal value because value lists are not allowed in constants.

Example 309

Assume a TTCN ASP Constraint C with parameters P1 and P2 (both of type integer). The parameter P1 has the value (2 + X) and P2 has the value (2 + Y, X). Both P1 and P2 have a correct value but the value of P1 is considered to be an Expression by the Analyzer.

ASN.1 AnyValue

This ASN.1 construct introduces ambiguities into the language. This is because it is hard to find the place where the Type ends and the Value starts.

A restricted form of AnyValue is supported where the Type in the AnyValue must be a reference to a user defined type. This form covers all cases for ASN.1 AnyValue.

Example 310

Assume the ASN.1 Type definition T:
SEQUENCE {f1 INTEGER, f2 LT1 DEFAULT {s1 2, s2 LT2 FALSE}}
LT1 ::= SEQUENCE {s1 INTEGER, s2 ANY}
LT2 ::= BOOLEAN

ASN.1 NamedType & NamedValue

According to the ASN.1 standard (12.5), in some notation within which a type is referenced, the type may be named. In such cases, the ASN.1 standard specifies the use of the notation NamedType which is defined as:

NamedType ::= identifier Type | Type | SelectionType

The value of a type referenced using the NamedType notation shall be defined by the notation NamedValue which is defined as:

NamedValue ::= identifier Value | Value

According to the Information Technology -OSI- ASN.1 (UDC 681.3:621.39) the identifier in the NamedType definition shall be mandatory. The same modification is suggested for the NamedValue.

The TTCN Analyzer do not allow use of the second alternative of either of these constructs, i.e. the naming identifiers are not optional.

Example 311

Assume that the ASN.1 type T is defined as:
SEQUENCE { x INTEGER, y < Element }
Element ::= CHOICE { x BOOLEAN, y INTEGER }
This type definition is legal. The ASN.1 NamedType in T (x & y) shall be unique (y is considered as a NamedType in this case).
A legal value for T is: {x 2, y 4}

Example 312

Assume another ASN.1 type, T', defined as:
SEQUENCE { x INTEGER, y x < Element }
Element ::= CHOICE { x INTEGER, y BOOLEAN }
This type definition is also legal. The ASN.1 NamedType in T' (x & y) shall be unique (x is not considered as a NamedType in this case).
The value {x 2, y 4} is not considered to be a legal value for T' even though it is allowed according to the ASN.1 standard. A legal value (which will be accepted by the Analyzer) is {x 2, y x 4}

An important point to be noticed is that the TTCN standard does not allow the usage of an ASN.1 NamedValue within arithmetic expressions: (TTCN standard, 10.3.2.2).

Data Object Reference

A consequence of the above described restriction is that the TTCN Suite does not permit the ComponentPosition mechanism for a DataObjectReference.

Another restriction for DataObjectReference is that the TTCN Suite only permits Record referencing via ComponentIdentifiers. The mixed use of ComponentIdentifier, PDU_Identifier, and StructIdentifier for Record Reference is very vaguely described in the Standard. Almost any interpretation of the usage leads to possible ambiguities in the language.

The corresponding grammar for RecordRef (production 311) will in the TTCN Suite be:

RecordRef ::= Dot ComponentIdentifier

The "path" leading down to the data object must be fully specified, i.e. all the component identifiers from the top to the bottom must be present.

Macro Value

The wildcard values "?", "*", or "-" may not in the TTCN Suite be used in a Constraint where the identifier for the ASP Parameter, PDU Field, CM Element, or Structured Type Element is replaced by the macro symbol.

The Standard does not explicitly permit this nor does it allow this. The interpretation of using the wildcards for macros would however be very ambiguous. Rather than imposing one of the possible interpretations the TTCN Suite will not allow the wildcards as macro values at all.

If wildcards are to be used as values for the elements that are inserted via macro expansion they must be written in the elements of a Structured Type Constraint that is referenced as macro value.


http://www.ibm.com/rational
Contents Index Previous Next