ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005553 | Part 01: TTCN-3 Core Language | Technical | public | 10-06-2010 12:34 | 22-07-2010 12:57

Reporter | Wolfgang Seka |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.1 (published 2011-06) | Fixed in Version | v4.2.2 (interim 2010) |
Clause Reference(s) | 8.2.3
Source (company - Author) | MCC160

Summary | 0005553: Interpretation of import mechanism

Description

There seem to be different interpretations of the import mechanism as defined in cl. 8.2.3 of part 1. That results in the problem, that some compilers require additional import statements but on the other hand according to quality checks these import statements are not necessary.
=> it shall be evaluated whether cl. 8.2.3 needs clarification and which mechanism is intended.
There is an example in the "Additional Information" illustrating the problem.
Note: out of six compilers three of them follow one interpretation and the other three follow the other interpretation.

Steps To Reproduce |

Additional Information

The following example shows in principle the problem we have in the LTE conformance test suite (note that there may be further similar problems).
Example:
ModuleA: type enumerated MyEnum_Type {valueX, valueY};
ModuleB: modulepar {
MyEnum_Type px_MyModulePar := valueX;
}
ModuleC: ...
if (px_MyModulePar == valueY) { ...}
...
Question: Does ModuleC need to import ModuleA to know about valueX and valueY ??
Reference: an argument that this import is not necessary can be restriction e) of cl. 8.2.3.1 - but the whole clause is hard to understand.

Tags | No tags attached.

Relationships

related to | 0005834 | closed | Ina Schieferdecker | Enumeration values are of local scope - example is to be corrected

Attached Files

CR5553_resolution.doc (143,872) 29-06-2010 18:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2383&type=bug
CR5553_resolution v2.doc (165,888) 01-07-2010 14:39
http://oldforge.etsi.org/mantis/file_download.php?file_id=2394&type=bug
CR5553_resolution v3.doc (168,448) 02-07-2010 11:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=2400&type=bug
CR5553_resolution v4.doc (171,520) 12-07-2010 16:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2407&type=bug
CR5553_resolution v5.doc (171,520) 13-07-2010 11:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2408&type=bug

Issue History
Date Modified | Username | Field | Change
10-06-2010 12:34 | Wolfgang Seka | New Issue |
10-06-2010 12:34 | Wolfgang Seka | Clause Reference(s) | => 8.2.3
10-06-2010 12:34 | Wolfgang Seka | Source (company - Author) | => MCC160
28-06-2010 16:11 | Gyorgy Rethy | Status | new => assigned
28-06-2010 16:11 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
29-06-2010 10:45 | Gyorgy Rethy | Note Added: 0009396 |
29-06-2010 10:46 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-06-2010 10:46 | Gyorgy Rethy | Target Version | => Edition 4.3.1 (not yet published)
29-06-2010 16:37 | Gyorgy Rethy | Note Added: 0009415 |
29-06-2010 16:41 | Gyorgy Rethy | Note Edited: 0009415 |
29-06-2010 16:43 | Gyorgy Rethy | Note Edited: 0009415 |
29-06-2010 16:48 | Gyorgy Rethy | Note Edited: 0009415 |
29-06-2010 17:01 | Gyorgy Rethy | Note Edited: 0009415 |
29-06-2010 17:01 | Gyorgy Rethy | Note Edited: 0009415 |
29-06-2010 17:06 | Gyorgy Rethy | Note Added: 0009418 |
29-06-2010 17:08 | Gyorgy Rethy | Note Edited: 0009418 |
29-06-2010 17:21 | Gyorgy Rethy | Note Edited: 0009418 |
29-06-2010 17:22 | Gyorgy Rethy | Note Edited: 0009415 |
29-06-2010 17:22 | Gyorgy Rethy | Note Edited: 0009418 |
29-06-2010 18:35 | Gyorgy Rethy | Note Edited: 0009418 |
29-06-2010 18:50 | Gyorgy Rethy | Note Added: 0009419 |
29-06-2010 18:52 | Gyorgy Rethy | File Added: CR5553_resolution.doc |
29-06-2010 18:53 | Gyorgy Rethy | Note Edited: 0009418 |
30-06-2010 11:11 | Jacob Wieland - Spirent | Note Added: 0009425 |
30-06-2010 11:44 | Gyorgy Rethy | Note Added: 0009426 |
30-06-2010 11:45 | Gyorgy Rethy | Note Edited: 0009426 |
30-06-2010 11:46 | Gyorgy Rethy | Note Edited: 0009426 |
30-06-2010 11:46 | Gyorgy Rethy | Note Edited: 0009426 |
30-06-2010 11:54 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
30-06-2010 11:54 | Gyorgy Rethy | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
30-06-2010 12:13 | Jacob Wieland - Spirent | Note Added: 0009428 |
30-06-2010 12:17 | Jacob Wieland - Spirent | Note Edited: 0009428 |
30-06-2010 12:20 | Jacob Wieland - Spirent | Note Edited: 0009428 |
30-06-2010 12:26 | Jacob Wieland - Spirent | Note Added: 0009429 |
30-06-2010 14:27 | Gyorgy Rethy | Note Added: 0009431 |
30-06-2010 14:31 | Gyorgy Rethy | Note Added: 0009432 |
30-06-2010 14:54 | Gyorgy Rethy | Note Edited: 0009431 |
30-06-2010 15:00 | Jacob Wieland - Spirent | Note Added: 0009433 |
30-06-2010 17:39 | Gyorgy Rethy | Note Added: 0009437 |
30-06-2010 17:40 | Gyorgy Rethy | Note Edited: 0009437 |
30-06-2010 17:42 | Gyorgy Rethy | Note Edited: 0009437 |
30-06-2010 17:43 | Gyorgy Rethy | Note Edited: 0009437 |
30-06-2010 17:45 | Gyorgy Rethy | Note Edited: 0009437 |
30-06-2010 17:46 | Gyorgy Rethy | Note Edited: 0009437 |
01-07-2010 11:26 | Jacob Wieland - Spirent | Note Added: 0009445 |
01-07-2010 12:01 | Gyorgy Rethy | Assigned To | Jens Grabowski => Gyorgy Rethy
01-07-2010 14:39 | Gyorgy Rethy | File Added: CR5553_resolution v2.doc |
01-07-2010 14:43 | Gyorgy Rethy | Note Added: 0009450 |
01-07-2010 14:45 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
02-07-2010 09:51 | Jens Grabowski | Note Added: 0009461 |
02-07-2010 09:51 | Jens Grabowski | Status | assigned => resolved
02-07-2010 09:51 | Jens Grabowski | Resolution | open => fixed
02-07-2010 09:54 | Jens Grabowski | Status | resolved => feedback
02-07-2010 09:54 | Jens Grabowski | Resolution | fixed => reopened
02-07-2010 09:54 | Jens Grabowski | Status | feedback => assigned
02-07-2010 09:54 | Jens Grabowski | Assigned To | Jens Grabowski => Ina Schieferdecker
02-07-2010 09:55 | Jens Grabowski | Status | assigned => resolved
02-07-2010 09:55 | Jens Grabowski | Resolution | reopened => fixed
02-07-2010 10:55 | Jacob Wieland - Spirent | Status | resolved => feedback
02-07-2010 10:55 | Jacob Wieland - Spirent | Resolution | fixed => reopened
02-07-2010 10:55 | Jacob Wieland - Spirent | Note Added: 0009465 |
02-07-2010 11:12 | Gyorgy Rethy | Status | feedback => assigned
02-07-2010 11:12 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Gyorgy Rethy
02-07-2010 11:12 | Gyorgy Rethy | Note Added: 0009467 |
02-07-2010 11:31 | Gyorgy Rethy | File Added: CR5553_resolution v3.doc |
02-07-2010 11:32 | Gyorgy Rethy | Note Added: 0009468 |
02-07-2010 12:05 | Jacob Wieland - Spirent | Note Added: 0009471 |
02-07-2010 12:32 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
02-07-2010 12:32 | Gyorgy Rethy | Status | assigned => resolved
07-07-2010 09:33 | Jens Grabowski | Status | resolved => feedback
07-07-2010 09:33 | Jens Grabowski | Note Added: 0009481 |
07-07-2010 09:35 | Jens Grabowski | Assigned To | Ina Schieferdecker => Gyorgy Rethy
07-07-2010 09:35 | Jens Grabowski | Status | feedback => assigned
12-07-2010 16:27 | Gyorgy Rethy | File Added: CR5553_resolution v4.doc |
12-07-2010 16:29 | Gyorgy Rethy | Note Added: 0009514 |
12-07-2010 16:29 | Gyorgy Rethy | Note Edited: 0009514 |
12-07-2010 16:30 | Gyorgy Rethy | Note Edited: 0009514 |
12-07-2010 16:31 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
12-07-2010 16:31 | Gyorgy Rethy | Note Edited: 0009514 |
13-07-2010 11:42 | Gyorgy Rethy | Note Added: 0009516 |
13-07-2010 11:43 | Gyorgy Rethy | Note Edited: 0009516 |
13-07-2010 11:43 | Gyorgy Rethy | File Added: CR5553_resolution v5.doc |
13-07-2010 11:57 | Jacob Wieland - Spirent | Note Added: 0009519 |
14-07-2010 10:35 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
14-07-2010 10:36 | Jacob Wieland - Spirent | Status | assigned => resolved
14-07-2010 10:36 | Jacob Wieland - Spirent | Fixed in Version | => Edition 4.2.2 (not yet published)
14-07-2010 10:36 | Jacob Wieland - Spirent | Resolution | reopened => fixed
22-07-2010 12:56 | Ina Schieferdecker | Note Added: 0009559 |
22-07-2010 12:56 | Ina Schieferdecker | Status | resolved => closed
30-11-2010 15:38 | Ina Schieferdecker | Relationship added | related to 0005834

Notes

(0009396)
Gyorgy Rethy
29-06-2010 10:45

Clarify the issue with Wolfgang. Analyze possible ambiguity of the current text.

(0009415)
Gyorgy Rethy
29-06-2010 16:37 (edited on: 29-06-2010 17:22)

Let complete and extend the example:
module A {
type enumerated MyEnum_Type {valueX, valueY}
type record MyRec { integer a, integer b }
type component MyComp { var MyRec v_Rec := { a := 5 } }
}
module B {
import from A all;
modulepar MyEnum_Type px_MyModulePar := valueY;
type component MyCompUser extends MyComp {}
}
module C {
import from B all;
//but some tools also requiring one of this:
// import from A all; //or
// import from B { import all }
testcase TC() runs on MyCompUser {
if (px_MyModulePar == valueY) {
log ("name valueY is know in C without explicit import");
setverdict(pass)
}
if (v_Rec.a == 5) {
v_Rec.b := v_Rec.a;
log ("Both the variable name v_Rec and the record field names are known in C without explicit import", v_Rec);
setverdict (pass)
}
}
control {
execute (TC())
}
}
The solution shall be consistent for both (and all similar) cases.

(0009418)
Gyorgy Rethy
29-06-2010 17:06 (edited on: 29-06-2010 18:53)

The standard currently specifies
in clause 8.2.3.1:
in Table 8: what are the local definitions of different importable definitions. Enumeration values are explicitly mentioned as local definitions of the enumerated type.
in Restrictions:
c) A definition is imported together with its name and all local definitions.
NOTE 5: A local definition, e.g. a field name of a user-defined record type, has only meaning in the context of the definitions in which it is defined, e.g. a field name of a record type can only be used to access a field of the record type and not outside this context.
d) A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5).
NOTE 6: If a module A imports a definition from module B that uses a type reference defined in module C, the corresponding information necessary for the usage of that type is automatically imported into module A. Identifiers of referenced definitions are not automatically imported.
------------------------------------end quotation-------------------------
My conclusion from the above is that the standard is clear enough: in module C of the example above no direct import from module A is needed to use the value valueY in the context of the module parameter px_MyModulePar.
But adding the example to the standard would not harm.

(0009419)
Gyorgy Rethy
29-06-2010 18:50

See proposed resolution in CR5553_resolution.doc.

(0009425)
Jacob Wieland - Spirent
30-06-2010 11:11

I completely DISAGREE!
The sentence
"A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5)." might imply what you mean, but since 'usage of the imported definition' is not clearly defined, it might also not.
Since it is not necessary to know valueX so that px_MyModulePar can be used in a lot of cases, I don't think that the above sentence applies here.
So, either it must be more clearly defined what 'necessary for the usage of the imported definition', especially for entities of enumerated types, means or the standard is ambiguous and so, of course, the tools can interpret this sentence however they want. All examples unfortunately focus only on field names necessary to write down values of structured types, so this does not help in clearing this up.
In my interpretation, the enumerated type should be directly (or via import import) imported so that its enumerated values are known in the importing module.

(0009426)
Gyorgy Rethy
30-06-2010 11:44 (edited on: 30-06-2010 11:46)

Hi Jacob,
Your comment is off target. The quoted sentence is about referenced definitions. What are they? e.g. in case of a record type:
module A {
type record MyRec { MyUnion u, MySetOf s }
}
the type definitions MyUnion and MySetOf are referenced from MyRec but they are not needed to assign a value to an instance of MyRec. e.g.
module B {
import from A { type MyRec }
const MyRec c_MyRec := { u := { somechoice := 5 }, {} }
}
Enumerated types do reference nothing, they just do define the value set of the type. This is given explicitly in Table 8:
.....................local defs_.............referenced defs
enumerated......concrete values.........-
struct. type....field names.............field types
....................nested type defs
So, I think my conclusion on what the standard specifies today is correct.
Btw. I think it is clear and also Wolfgang's example shows that the allowed values of a type are necessary to use of the instance of that type.

(0009428)
Jacob Wieland - Spirent
30-06-2010 12:13 (edited on: 30-06-2010 12:20)

Yes, there are SOME usages, where the value needs to be known (i.e. those are those, where the value should be imported explicitly via importing its type), but there are also lots of usages, where the values do not need to be known: usage as parameter, usage as assignment, usage as comparison with another (non-enum-value) expression, etc. etc.
So, NO, it is not clear that the implicit import of the values of the type of an enum-modulepar is necessary for the usage of that modulepar.
Also, my comment was NOT off target. The imported definition was the modulepar. This definition references the enum type. The implicit information necessary for the usage of that referenced enum type would be the enum values defined by that type.
To illustrate my interpretation, take the following example:
module A {
type enumerated E { a, b }
function f(E x) { ... }
}
module B {
import from A { type E }
modulepar E b;
}
module C {
import from A { function f }
import from B { modulepar b }
function g() {
f(b); // If the implicit-import-of-enum-values interpretation is used
// this should be ambiguous (A.b vs. B.b),
// even though everything used is apparently
// explicitly imported
}
}
This example shows how confusing such implicit imports can be. If it is not possible to avoid name-clashes even in cases where everything is imported explicitly, I don't think that speaks for a good language design.
Therefore, I stand by my opinion that the local names of enumerated values should only be known, if their type is EXPLICITLY imported. That way, no such confusion can arise.
If you are about to argue that that would be different than for really structured types (record/union/set), then I would argue that there, the names are only usable locally (in a field-assignment context or in a field reference) so there can be no nameclashes with other imported identifiers like for enumerated values.

(0009429)
Jacob Wieland - Spirent
30-06-2010 12:26

Since I don't want to appear all destructive, I will propose a constructive solution to the problem posed by implict imports, as well:
If an enum-value name (and those are the only ones that cause such nameclash-problem) is imported explicitly and implicitly, the identifier shall be resolved using the explicit import in favor of the implicit import.
Thereby, it is possible for the user to control (via explicit imports) which names should be unambiguous in their module.
Such a sentence would need to be added to the definition of the import statement.

(0009431)
Gyorgy Rethy
30-06-2010 14:27 (edited on: 30-06-2010 14:54)

Hi Jacob,
OK let's take a cold start. When we talk about "transitive import" like in the case
module A defines type -> module B defines value -> module C uses the value;
you are right, the value imported to module C will have a referenced definition, as you correctly wrote "The imported definition was the modulepar. This definition references the enum type. The implicit information necessary for the usage of that referenced enum type would be the enum values defined by that type."
But I don't understand why in this concrete case the enumeration values should not be imported. As I quoted above,
"d) A definition is imported together with all information of referenced definitions that are necessary for the usage of the imported definition, independent of the visibility of the referenced definitions (see clause 8.2.5).
NOTE 6: If a module A imports a definition from module B that uses a type reference defined in module C, the corresponding information necessary for the usage of that type is automatically imported into module A. Identifiers of referenced definitions are not automatically imported."
In the note exactly the case we are talking about is described. So, I do not understand, where is the ambiguity?
Can the equality if (px_MyModulePar == valueY) be executed (or even checked) without knowing the values of the type? I don't think so. So, at least in this concrete case, into this concrete module C the module parameter shall be imported together with the "information necessary for the usage of a referenced definition"; if it is not done like this, the concrete tool in this concrete case fails to comply with the standard.
Pls. note, that enumeration values ARE NOT GLOBAL NAMES. They have meaning in the context of the given enumerated type only. This is true even if they impose some restriction on global names. So, e.g. in the case
module A {
type enumerated Enum { e1, e2 }
}
module B {
import from A all;
const integer e1 := 1;
const integer e2 := e1;
}
no name clash occur as in module B the name e1 and e2 are used in the context of the integer type! This is defined unambiguously in $6.2.4: "Enumeration identifiers shall be unique within the enumerated type (but do not have to be globally unique) and are consequently visible within the context of the given type only."
I don't understand why are you writing that "If it is not possible to avoid name-clashes even in cases where everything is imported explicitly, I don't think that speaks for a good language design." ? In TTCN-3 it is possible to avoid name clashes by using the qualified names. It is also unclear to me how an explicit import statement would help solving name clashes. The rules today are not importing the name "Enum" in the example above. 1 name less in module B. But users tend to like short code lines, so they are practically always using the import all option. And this results importing a lots of names that are not referenced at all in the importing module. So, your proposal would be very unpractical, not giving any advantage, but causing a lots of unnecessary extra (potential) name clashes.
And one more point. Changing the standard would raise a huge backward compatibility problem. Users of tools working according to the standard, i.e. not requiring import from A in module C, have no import statements in their codes. Therefore changing the standard would be an issue for them. Users of the tools requiring the extra import statement will not notice anything if the tool "below them" changes to the standard behaviour. So, for them there is no compatibility problem.

(0009432)
Gyorgy Rethy
30-06-2010 14:31

My comment posted at 13:27 responded to Jacob's comment posted at 11:13. While writing a comment, no new contributions can be seen. Jacob, could you pls. elaborate more on your proposal, probably an example would help to understand it. Have you noticed the sentence(s) in the proposal saying, that names of the values take precedence over global definition names?

(0009433)
Jacob Wieland - Spirent
30-06-2010 15:00

> Jacob, could you pls. elaborate more on your proposal, probably an example would help to understand it.
I'll give a few examples:
module A {
type enumerated E { a, b }
function f(E x) { ... }
}
module B {
import from A { function f }
function g() {
f(a); // => f(A.a) because of implicit import and parameter context
}
}
module C {
import from A { type E }
modulepar E b, x;
}
module D {
import from C { modulepar x, b }
type enumerated E2 { a, b }
function g() {
if (x == a) { // works (C.x == A.a)
}
if (x == b) { // works (C.x == C.b)
}
if (a == b) { // works (A.a == C.b) (there is no context suggesting E2)
}
}
}
module F {
import from A { function f }
import from C { modulepar b }
function g() {
f(b); // => f(C.b) because of explicit import
if (b == a) { // => (C.b == A.a) because of explicit import
}
}
}
> Have you noticed the sentence(s) in the proposal saying, that names of the values take precedence over global definition names?
Yes, and I'm more in favor of the other way around, if the enumerated type is the same.
On account of the backward compatibility issue for the tools that up-to-now interpreted the enum values without explicit import of the enum types, you are right. But, I think my new proposal addresses this issue adequately.
On the question of disambiguation by the user: There are always two ways to resolve name-clashes (at least, there should be): fewer imports (i.e. explicit imports) or use of qualified names. Since using the qualified names at a thousand places is probably more unacceptable than changing one import statement (to exclude an enumerated type whose values I don't want to use explicitly), I think that the users will rather use the latter than the former, even though the former is always more robust against later changes.
But, if a testsuite opts for the non-lazy approach of using explicit imports, they should be able to control via these imports how the unqualified names shall be resolved. Otherwise, the explicit import is a feature that nobody needs because if it does not help in disambiguation, what is it good for?

(0009437)
Gyorgy Rethy
30-06-2010 17:39 (edited on: 30-06-2010 17:46)

OK, we are closer now. Let's look at your examples:
module D {
function g() {
if (x == a) { // works (C.x == A.a)
//Gy: I agree
}
if (x == b) { // works (C.x == C.b)
/*Gy: how to compare x with value b of E1? As value b is not a global name, cannot be prefixed. The only way to distinguish them unambiguously is to use the local value without prefix and the global name with an explicit prefix, i.e. x == C.b. This is also more consistent with the previous case, where the name a (without prefix) means the local name. Think about the writer of module D, importing all from module C (this is a usual way of importing), later someone adds a definition with name b to module C and suddenly "by magic" and, mainly without any notification, the behaviour of module D changes! Think about the tester debugging, why his regression test changed verdict from one day to another :(( */
}
if (a == b) { // works (A.a == C.b) (there is no context suggesting E2)
// Gy: I agree
}
}
}
module F {
function g() {
f(b); // => f(C.b) because of explicit import
/* Gy: don't agree, the formal parameter of f is of type E that creates the context. The same backward compatibility problem exists as with the x==b example above */
if (b == a) { // => (C.b == A.a) because of explicit import
// Gy: I agree
}
}
}

(0009445)
Jacob Wieland - Spirent
01-07-2010 11:26

If it is true that the enum-value-names cannot be prefixed by the module-name of the module that introduced them (which is another weakness in the whole proposal in my opinion), then of course, you are right that they must have precedence if the context can be clearly determined as an enumerated type as otherwise, they cannot be used in a context that also imports/declares the same name (with the same type).

(0009450)
Gyorgy Rethy
01-07-2010 14:43

More detailed clarification on the type context is added to CR5553_resolution v2.doc and a few more examples. Pls. cross-check it.

(0009461)
Jens Grabowski
02-07-2010 09:51

proofreading OK

(0009465)
Jacob Wieland - Spirent
02-07-2010 10:55

I have one more problem: backward compatibility the other way around.
There will be a lot of test-suites that used the interpretation of our tool that the enum-value-names are (kind of) global names introduced by the module where they are declared and therefore can be prefixed with the module name for disambiguation purposes.
For backward compatibility of these test-suites it would be good if such qualified names would still be explicitly allowed (maybe as a deprecated feature so the tools can warn the users that this is not a wanted feature anymore).

(0009467)
Gyorgy Rethy
02-07-2010 11:12

Good point, I will add this as a deprecated feature.

(0009468)
Gyorgy Rethy
02-07-2010 11:32

Added to CR5553_resolution v3.doc, pls. review.

(0009471)
Jacob Wieland - Spirent
02-07-2010 12:05

OK by me.

(0009481)
Jens Grabowski
07-07-2010 09:33

Request from Andrus Lehtmets (Elvior): Add following note: "NOTE 7: If a module B imports a value or template or parameter of an enumerated type from module A, the enumerated values of this type including identifiers are automatically imported to module B."

(0009514)
Gyorgy Rethy
12-07-2010 16:29 (edited on: 12-07-2010 16:31)

CR5553_resolution v4.doc: The proposed note is re-worded and added to existing Note 6 as a new paragraph (but with unchanged technical content). Pls. proof-read.

(0009516)
Gyorgy Rethy
13-07-2010 11:42 (edited on: 13-07-2010 11:43)

"Implicit" (importing) and a sentence on use of the values are added to the new paragraph of the note. Pls. proof-read, if OK, set to resolved and assign to Ina.

(0009519)
Jacob Wieland - Spirent
13-07-2010 11:57

I think this is now sufficiently clear (together with the examples)

(0009559)
Ina Schieferdecker
22-07-2010 12:56

small editorials