Following up on the previous discussion about encoding attributes, I would like to propose the following approach:
1) Encoding attributes 'apply' only to type definitions. They can be stated for module, group, type, and import definition, and have a _static_ influence on the encoding attribute for a type, which is fixed at compile time. Encoding attributes may not be stated for function, altstep, testcase, modulepar, constant, component, or value definition. When these definitions are inside a group/module that specified encoding attributes, these have no effect on the previously mentioned definitions.
When an encoding attribute is specified in a port definition, it affects the ecoding attributes for the types mentioned in the in- and out-list of this port, and not what encoding is to be used when sending a port instance of this port type (which does not make much sense anyway). This issue is particularly important in the light of item 3 below.
2) Some more formal way of defining how the static encoding attributes are determined at compile time is necessary. I have proposed a possible algorithm for this at an earlier point. I agree that it is relatively complicated for such a simple task. It does not really matter how the actual encoding attribute for a type is determined from its enclosing group/module/import/port definitions, but there should be one an unambiguous, explicitly explained way of determining the actual encoding attribute for a type. Volunteers, anybody?
3) Selection of which encoding attribute is selected at runtime: currently, the standard does not mention any way in which the dynamic encoding attribute to be used in a send-like statement is determined. I would propose the following approach:
Sending a value x of type T on some port P requires requires that T occurs in the out-list of the port P' that P is currently mapped to. Note that it really must be T in the out-list of P' because of the strict type compatibility rules required for port compatibility. In the port definition of P', T must be known and hence also the encoding attributes for that particular instance of T is statically known. This encoding attributes are to be used when the value x is being sent.
Tying the encoding attributes to the port definition rather than the value makes is possible to modify the dynamically chose encoding attrbute using the normal configuration mechanism of TTCN-3.
The same mechanism as in 1,2, and 3 should be used for encoding variations.
Opinions?
Best regards
Stephan Tobies
