TOPIC:

Dear all,

is the following type definition allowed if A, B and C are already used as
identifiers for other types?

type record sample_record_type {
A A,
B B,
C C
}

The core spec (3.4.1) says in 5.2.2:

"TTCN-3 requires uniqueness of identifiers, i.e. all identifiers in the
same scope hierarchy shall be distinctive. This means that a declaration in
a lower level of scope shall not re-use the same identifier as a
declaration in a higher level of scope in the same branch of the scope
hierarchy. Identifiers for fields of structured types, enumeration values
and groups do not have to be globally unique, however in the case of
enumeration values the identifiers shall only be reused for enumeration
values within other enumerated types."

In my understanding the identifiers of enumeration values may only be
reused for other enumeration values. Does a similar restriction apply for
fields of structured types or is it allowed to reuse the identifiers of
fields of structured types e. g. for other type names? Are there any
details or examples in the spec on this?

Thanks in advance and regards,

Corinna

---

Corinna Wiegert
Rohde & Schwarz GmbH & Co. KG
Test and Measurement Division, Dept. 1SP4
P.O. Box 80 14 69
81614 München / GERMANY

Tel: +49-89-4129-13498
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Web: www.rohde-schwarz.com

---

Hi Corinna,

Your example is possible because you can have a subtype field with the same
name that its type. The type and the field have different scope then there
is no problem.

type record sample_record_type {
A A,
B B,
C C
}



The enumerated types:

There isn't the same restriction for structured types; it's only for
enumerated types.
You can see enumerated examples on the page 41 (core v3.4.1).


Elena de Vega Gil


TEL: (+34) 91 353 15 64

FAX: (+34) 91 359 61 79

E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.







Metodos Y Tecnología (MTP)

Paseo de la Castellana 182, 10

28046 Madrid, España

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
Enviado el: jueves, 25 de septiembre de 2008 14:05
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Uniqueness of identifiers

Dear all,

is the following type definition allowed if A, B and C are already used as
identifiers for other types?

type record sample_record_type {
A A,
B B,
C C
}

This is possible because you can have a subtype field with the same name
that its type. The type and the field have different scope then there are
not problem.

The core spec (3.4.1) says in 5.2.2:

"TTCN-3 requires uniqueness of identifiers, i.e. all identifiers in the
same scope hierarchy shall be distinctive. This means that a declaration in
a lower level of scope shall not re-use the same identifier as a
declaration in a higher level of scope in the same branch of the scope
hierarchy. Identifiers for fields of structured types, enumeration values
and groups do not have to be globally unique, however in the case of
enumeration values the identifiers shall only be reused for enumeration
values within other enumerated types."

In my understanding the identifiers of enumeration values may only be
reused for other enumeration values. Does a similar restriction apply for
fields of structured types or is it allowed to reuse the identifiers of
fields of structured types e. g. for other type names? Are there any
details or examples in the spec on this?

Thanks in advance and regards,

Corinna

---

Corinna Wiegert
Rohde & Schwarz GmbH & Co. KG
Test and Measurement Division, Dept. 1SP4
P.O. Box 80 14 69
81614 München / GERMANY

Tel: +49-89-4129-13498
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Web: www.rohde-schwarz.com

---

=

Hello Elena and Corinna,

It's my understanding that Corinna's example is invalid. The same identifier has been used twice in the same scope unit (the module), once as identifier of a type and once as identifier of a field.

Regarding uniqueness of fieldnames of different record types and of enumeration values.

type record R1 { integer a, boolean b};
type record R2 { integer a, boolean b};
type enumerated E1 {c};

would be ok. What's not ok is to define in addition:

type enumerated E2 { b, c };

The identifier b can be used only as an enumeration value. But it is also used as fieldname of a record. The definition of the enumeration value c in both enumerations E1 and E2 is fine.

That's my understanding of clause 5.2.2.

Hope this helps ... stimulates discussion to clarify this issue. Seems that the standards leaves room for interpretation.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Elena de Vega
>Sent: Thursday, 25. September 2008 16:15
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Uniqueness of identifiers
>
>Hi Corinna,
>
>Your example is possible because you can have a subtype field
>with the same name that its type. The type and the field have
>different scope then there is no problem.
>
>type record sample_record_type {
> A A,
> B B,
> C C
> }
>
>
>
>The enumerated types:
>
>There isn't the same restriction for structured types; it's
>only for enumerated types.
>You can see enumerated examples on the page 41 (core v3.4.1).
>
>
>Elena de Vega Gil
>
>
>TEL: (+34) 91 353 15 64
>
>FAX: (+34) 91 359 61 79
>
>E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>
>
>
>
>
>
>Metodos Y Tecnología (MTP)
>
>Paseo de la Castellana 182, 10
>
>28046 Madrid, España
>
>
>
>
>

---

Mensaje original

---

>De: active_ttcn3 : mts stf133 ttcn version 3 - active members
>only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
>Enviado el: jueves, 25 de septiembre de 2008 14:05
>Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Asunto: Uniqueness of identifiers
>
>Dear all,
>
>is the following type definition allowed if A, B and C are
>already used as identifiers for other types?
>
>type record sample_record_type {
> A A,
> B B,
> C C
> }
>
>This is possible because you can have a subtype field with the
>same name that its type. The type and the field have different
>scope then there are not problem.
>
>The core spec (3.4.1) says in 5.2.2:
>
>"TTCN-3 requires uniqueness of identifiers, i.e. all
>identifiers in the same scope hierarchy shall be distinctive.
>This means that a declaration in a lower level of scope shall
>not re-use the same identifier as a declaration in a higher
>level of scope in the same branch of the scope hierarchy.
>Identifiers for fields of structured types, enumeration values
>and groups do not have to be globally unique, however in the
>case of enumeration values the identifiers shall only be
>reused for enumeration values within other enumerated types."
>
>In my understanding the identifiers of enumeration values may
>only be reused for other enumeration values. Does a similar
>restriction apply for fields of structured types or is it
>allowed to reuse the identifiers of fields of structured types
>e. g. for other type names? Are there any details or examples
>in the spec on this?
>
>Thanks in advance and regards,
>
>Corinna
>
>
>

---

>

---

>Corinna Wiegert
>Rohde & Schwarz GmbH & Co. KG
>Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
>81614 München / GERMANY
>
>Tel: +49-89-4129-13498
>Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Web: www.rohde-schwarz.com
>

---

>

---

=
>

Hello Thomas,

I disagree, I think the example is totally valid.

Record 'scopes' are not scope units as statement blocks or the module
body. There is no conflict as these names can only be used
on the left hand side of a field assignment or on the right hand side of
a dot. Thus, they can never be confused with names declared
in the same scope. The only restriction is that inside the same
record/set 'scope', the field names must be unique to avoid
nameclashes between them.

I also think that that is what the standard describes when referencing
the exception of field names which Elena quoted.

If your reasoning were true, then it should also not be possible to
introduce a record with a field f which is itself again
a record with field f. But, since the first field f could also have a
record type with a field f which was declared in a different module,
this would have to be disallowed as well (even though in both cases
there is no name conflict anywhere), but isn't.

Thus, either your reasoning is flawed or the standard is inconsistent.
In this instant, I vote the former ;-)

Best regards,

Jacob Wieland

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
> Hello Elena and Corinna,
>
> It's my understanding that Corinna's example is invalid. The same identifier has been used twice in the same scope unit (the module), once as identifier of a type and once as identifier of a field.
>
> Regarding uniqueness of fieldnames of different record types and of enumeration values.
>
> type record R1 { integer a, boolean b};
> type record R2 { integer a, boolean b};
> type enumerated E1 {c};
>
> would be ok. What's not ok is to define in addition:
>
> type enumerated E2 { b, c };
>
> The identifier b can be used only as an enumeration value. But it is also used as fieldname of a record. The definition of the enumeration value c in both enumerations E1 and E2 is fine.
>
> That's my understanding of clause 5.2.2.
>
> Hope this helps ... stimulates discussion to clarify this issue. Seems that the standards leaves room for interpretation.
>
> Best regards
>
> Thomas
>
>

---

|
> | Thomas Deiß |
> | Nokia Siemens Networks |
> | Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
> | Internal: 828 3584 |
> | Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
> | email: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

|
>
>
>
>>

---

Original Message

---

>> From: active_ttcn3 : mts stf133 ttcn version 3 - active
>> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>> Elena de Vega
>> Sent: Thursday, 25. September 2008 16:15
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Subject: Re: Uniqueness of identifiers
>>
>> Hi Corinna,
>>
>> Your example is possible because you can have a subtype field
>> with the same name that its type. The type and the field have
>> different scope then there is no problem.
>>
>> type record sample_record_type {
>> A A,
>> B B,
>> C C
>> }
>>
>>
>>
>> The enumerated types:
>>
>> There isn't the same restriction for structured types; it's
>> only for enumerated types.
>> You can see enumerated examples on the page 41 (core v3.4.1).
>>
>>
>> Elena de Vega Gil
>>
>>
>> TEL: (+34) 91 353 15 64
>>
>> FAX: (+34) 91 359 61 79
>>
>> E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.
>>
>>
>>
>>
>>
>>
>>
>> Metodos Y Tecnología (MTP)
>>
>> Paseo de la Castellana 182, 10
>>
>> 28046 Madrid, España
>>
>>
>>
>>
>>

---

Mensaje original

---

>> De: active_ttcn3 : mts stf133 ttcn version 3 - active members
>> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
>> Enviado el: jueves, 25 de septiembre de 2008 14:05
>> Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Asunto: Uniqueness of identifiers
>>
>> Dear all,
>>
>> is the following type definition allowed if A, B and C are
>> already used as identifiers for other types?
>>
>> type record sample_record_type {
>> A A,
>> B B,
>> C C
>> }
>>
>> This is possible because you can have a subtype field with the
>> same name that its type. The type and the field have different
>> scope then there are not problem.
>>
>> The core spec (3.4.1) says in 5.2.2:
>>
>> "TTCN-3 requires uniqueness of identifiers, i.e. all
>> identifiers in the same scope hierarchy shall be distinctive.
>> This means that a declaration in a lower level of scope shall
>> not re-use the same identifier as a declaration in a higher
>> level of scope in the same branch of the scope hierarchy.
>> Identifiers for fields of structured types, enumeration values
>> and groups do not have to be globally unique, however in the
>> case of enumeration values the identifiers shall only be
>> reused for enumeration values within other enumerated types."
>>
>> In my understanding the identifiers of enumeration values may
>> only be reused for other enumeration values. Does a similar
>> restriction apply for fields of structured types or is it
>> allowed to reuse the identifiers of fields of structured types
>> e. g. for other type names? Are there any details or examples
>> in the spec on this?
>>
>> Thanks in advance and regards,
>>
>> Corinna
>>
>>
>>

---

>>

---

>> Corinna Wiegert
>> Rohde & Schwarz GmbH & Co. KG
>> Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
>> 81614 München / GERMANY
>>
>> Tel: +49-89-4129-13498
>> Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Web: www.rohde-schwarz.com
>>

---

>>

---

=
>>
>>
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi,

When you define a record, this has its own scope, so you can repeat
identifiers form higher, levels and reference the new fields with the name
of the record as a path. Fields in a record are not global, so there is no
problem of collision related to the identifiers.

That is the reason why in my opinion the example of the record given by
Corinna is correct.


 
Iván Navarro Azurmendi
 

 
Pº de la Castellana, 182 - 10ª planta
28046 - Madrid
Tel.:  +34 913531564
Fax: +34 913596179
www.mtp.es

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Deiss, Thomas (NSN -
DE/Duesseldorf)
Enviado el: jueves, 25 de septiembre de 2008 16:15
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Re: Uniqueness of identifiers

Hello Elena and Corinna,

It's my understanding that Corinna's example is invalid. The same identifier
has been used twice in the same scope unit (the module), once as identifier
of a type and once as identifier of a field.

Regarding uniqueness of fieldnames of different record types and of
enumeration values.

type record R1 { integer a, boolean b};
type record R2 { integer a, boolean b};
type enumerated E1 {c};

would be ok. What's not ok is to define in addition:

type enumerated E2 { b, c };

The identifier b can be used only as an enumeration value. But it is also
used as fieldname of a record. The definition of the enumeration value c in
both enumerations E1 and E2 is fine.

That's my understanding of clause 5.2.2.

Hope this helps ... stimulates discussion to clarify this issue. Seems that
the standards leaves room for interpretation.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Elena de Vega
>Sent: Thursday, 25. September 2008 16:15
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: Uniqueness of identifiers
>
>Hi Corinna,
>
>Your example is possible because you can have a subtype field
>with the same name that its type. The type and the field have
>different scope then there is no problem.
>
>type record sample_record_type {
> A A,
> B B,
> C C
> }
>
>
>
>The enumerated types:
>
>There isn't the same restriction for structured types; it's
>only for enumerated types.
>You can see enumerated examples on the page 41 (core v3.4.1).
>
>
>Elena de Vega Gil
>
>
>TEL: (+34) 91 353 15 64
>
>FAX: (+34) 91 359 61 79
>
>E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>
>
>
>
>
>
>Metodos Y Tecnología (MTP)
>
>Paseo de la Castellana 182, 10
>
>28046 Madrid, España
>
>
>
>
>

---

Mensaje original

---

>De: active_ttcn3 : mts stf133 ttcn version 3 - active members
>only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
>Enviado el: jueves, 25 de septiembre de 2008 14:05
>Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Asunto: Uniqueness of identifiers
>
>Dear all,
>
>is the following type definition allowed if A, B and C are
>already used as identifiers for other types?
>
>type record sample_record_type {
> A A,
> B B,
> C C
> }
>
>This is possible because you can have a subtype field with the
>same name that its type. The type and the field have different
>scope then there are not problem.
>
>The core spec (3.4.1) says in 5.2.2:
>
>"TTCN-3 requires uniqueness of identifiers, i.e. all
>identifiers in the same scope hierarchy shall be distinctive.
>This means that a declaration in a lower level of scope shall
>not re-use the same identifier as a declaration in a higher
>level of scope in the same branch of the scope hierarchy.
>Identifiers for fields of structured types, enumeration values
>and groups do not have to be globally unique, however in the
>case of enumeration values the identifiers shall only be
>reused for enumeration values within other enumerated types."
>
>In my understanding the identifiers of enumeration values may
>only be reused for other enumeration values. Does a similar
>restriction apply for fields of structured types or is it
>allowed to reuse the identifiers of fields of structured types
>e. g. for other type names? Are there any details or examples
>in the spec on this?
>
>Thanks in advance and regards,
>
>Corinna
>
>
>

---

>

---

>Corinna Wiegert
>Rohde & Schwarz GmbH & Co. KG
>Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
>81614 München / GERMANY
>
>Tel: +49-89-4129-13498
>Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Web: www.rohde-schwarz.com
>

---

>

---

=
>

Hi Everyone,



CorinnaÂ’s and JacobÂ’s analysis are correct.




type record sample_record_type { // this type is completely legal.
A A,
B B,
C C

}



type record sample_record_type { // this type is illegal.
A A,
B B,
C C,
C D // TTCN-3 requires uniqueness of
identifiers within the same
// scope branch as well as within a given
record or set.
// If this were legal, there would need to
be a way to determine
// which C is being referenced. In the
case of template definition
// field ordering can be used to determine
this, but in an assignment
// this would only be possible by tagging
the field with its type.

// It just easier to avoid such things to
start with.

}





Whichever the case, I would not recommend defining records where the field
name and the field type is the same. Even if it is allowed, its simply
asking for trouble. Why would someone want to create such needless
confusion???



Just my two cents for this evening. :-)









Claude.



BluKaktus Communications phone: +49 (0)30 9606 7985

Edinburger Str. 39 fax: +49 (0)30 9606 7987

13349 Berlin mobile: +49 (0)174 701 6792

Germany email: This email address is being protected from spambots. You need JavaScript enabled to view it.



_____

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: September 25, 2008 5:32 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers



Hello Thomas,

I disagree, I think the example is totally valid.

Record 'scopes' are not scope units as statement blocks or the module body.
There is no conflict as these names can only be used
on the left hand side of a field assignment or on the right hand side of a
dot. Thus, they can never be confused with names declared
in the same scope. The only restriction is that inside the same record/set
'scope', the field names must be unique to avoid
nameclashes between them.

I also think that that is what the standard describes when referencing the
exception of field names which Elena quoted.

If your reasoning were true, then it should also not be possible to
introduce a record with a field f which is itself again
a record with field f. But, since the first field f could also have a record
type with a field f which was declared in a different module,
this would have to be disallowed as well (even though in both cases there is
no name conflict anywhere), but isn't.

Thus, either your reasoning is flawed or the standard is inconsistent. In
this instant, I vote the former ;-)

Best regards,

Jacob Wieland

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Elena and Corinna,

It's my understanding that Corinna's example is invalid. The same identifier
has been used twice in the same scope unit (the module), once as identifier
of a type and once as identifier of a field.

Regarding uniqueness of fieldnames of different record types and of
enumeration values.

type record R1 { integer a, boolean b};
type record R2 { integer a, boolean b};
type enumerated E1 {c};

would be ok. What's not ok is to define in addition:

type enumerated E2 { b, c };

The identifier b can be used only as an enumeration value. But it is also
used as fieldname of a record. The definition of the enumeration value c in
both enumerations E1 and E2 is fine.

That's my understanding of clause 5.2.2.

Hope this helps ... stimulates discussion to clarify this issue. Seems that
the standards leaves room for interpretation.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
Elena de Vega
Sent: Thursday, 25. September 2008 16:15
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers

Hi Corinna,

Your example is possible because you can have a subtype field
with the same name that its type. The type and the field have
different scope then there is no problem.

type record sample_record_type {
A A,
B B,
C C
}



The enumerated types:

There isn't the same restriction for structured types; it's
only for enumerated types.
You can see enumerated examples on the page 41 (core v3.4.1).


Elena de Vega Gil


TEL: (+34) 91 353 15 64

FAX: (+34) 91 359 61 79

E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.







Metodos Y Tecnología (MTP)

Paseo de la Castellana 182, 10

28046 Madrid, España

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members
only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
Enviado el: jueves, 25 de septiembre de 2008 14:05
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Uniqueness of identifiers

Dear all,

is the following type definition allowed if A, B and C are
already used as identifiers for other types?

type record sample_record_type {
A A,
B B,
C C
}

This is possible because you can have a subtype field with the
same name that its type. The type and the field have different
scope then there are not problem.

The core spec (3.4.1) says in 5.2.2:

"TTCN-3 requires uniqueness of identifiers, i.e. all
identifiers in the same scope hierarchy shall be distinctive.
This means that a declaration in a lower level of scope shall
not re-use the same identifier as a declaration in a higher
level of scope in the same branch of the scope hierarchy.
Identifiers for fields of structured types, enumeration values
and groups do not have to be globally unique, however in the
case of enumeration values the identifiers shall only be
reused for enumeration values within other enumerated types."

In my understanding the identifiers of enumeration values may
only be reused for other enumeration values. Does a similar
restriction apply for fields of structured types or is it
allowed to reuse the identifiers of fields of structured types
e. g. for other type names? Are there any details or examples
in the spec on this?

Thanks in advance and regards,

Corinna

---

---

Corinna Wiegert
Rohde & Schwarz GmbH & Co. KG
Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
81614 München / GERMANY

Tel: +49-89-4129-13498
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Web: www.rohde-schwarz.com

---

---

=











--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi Claude,

I believe you mistyped -- your 2nd sample is legal, too!

Roland.

> type record sample_record_type { // this type is illegal.
> A A,
> B B,
> C C,
> C D
> }

Hi Claude,

Your analysis, unfortunately, is incorrect.
"
type record sample_record_type { // this type is illegal.
A A,
B B,
C C,
C D // TTCN-3 requires uniqueness of identifiers within the same
"
is perfectly legal. the standard says in $6.2.1: "The element identifiers are local to the record and shall be unique within the record (but do not have to be globally unique). " The element identifiers are A,B,C and D, they are unique. Dont mix element identifiers by the type of the elements. In all references (value notations, template definitions, just referring a field etc.) only the element identifiers are used, never their type.

BR, Gyorgy

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Claude Desroches
Sent: 2008. szeptember 25. 20:20
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers



Hi Everyone,



Corinna's and Jacob's analysis are correct.




type record sample_record_type { // this type is completely legal.
A A,
B B,
C C

}



type record sample_record_type { // this type is illegal.
A A,
B B,
C C,
C D // TTCN-3 requires uniqueness of identifiers within the same
// scope branch as well as within a given record or set.
// If this were legal, there would need to be a way to determine
// which C is being referenced. In the case of template definition
// field ordering can be used to determine this, but in an assignment
// this would only be possible by tagging the field with its type.

// It just easier to avoid such things to start with.

}





Whichever the case, I would not recommend defining records where the field name and the field type is the same. Even if it is allowed, its simply asking for trouble. Why would someone want to create such needless confusion???



Just my two cents for this evening. :-)









Claude.



BluKaktus Communications phone: +49 (0)30 9606 7985

Edinburger Str. 39 fax: +49 (0)30 9606 7987

13349 Berlin mobile: +49 (0)174 701 6792

Germany email: This email address is being protected from spambots. You need JavaScript enabled to view it.




________________________________


From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: September 25, 2008 5:32 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers



Hello Thomas,

I disagree, I think the example is totally valid.

Record 'scopes' are not scope units as statement blocks or the module body. There is no conflict as these names can only be used
on the left hand side of a field assignment or on the right hand side of a dot. Thus, they can never be confused with names declared
in the same scope. The only restriction is that inside the same record/set 'scope', the field names must be unique to avoid
nameclashes between them.

I also think that that is what the standard describes when referencing the exception of field names which Elena quoted.

If your reasoning were true, then it should also not be possible to introduce a record with a field f which is itself again
a record with field f. But, since the first field f could also have a record type with a field f which was declared in a different module,
this would have to be disallowed as well (even though in both cases there is no name conflict anywhere), but isn't.

Thus, either your reasoning is flawed or the standard is inconsistent. In this instant, I vote the former ;-)

Best regards,

Jacob Wieland

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Elena and Corinna,

It's my understanding that Corinna's example is invalid. The same identifier has been used twice in the same scope unit (the module), once as identifier of a type and once as identifier of a field.

Regarding uniqueness of fieldnames of different record types and of enumeration values.

type record R1 { integer a, boolean b};
type record R2 { integer a, boolean b};
type enumerated E1 {c};

would be ok. What's not ok is to define in addition:

type enumerated E2 { b, c };

The identifier b can be used only as an enumeration value. But it is also used as fieldname of a record. The definition of the enumeration value c in both enumerations E1 and E2 is fine.

That's my understanding of clause 5.2.2.

Hope this helps ... stimulates discussion to clarify this issue. Seems that the standards leaves room for interpretation.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
Elena de Vega
Sent: Thursday, 25. September 2008 16:15
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers

Hi Corinna,

Your example is possible because you can have a subtype field
with the same name that its type. The type and the field have
different scope then there is no problem.

type record sample_record_type {
A A,
B B,
C C
}



The enumerated types:

There isn't the same restriction for structured types; it's
only for enumerated types.
You can see enumerated examples on the page 41 (core v3.4.1).


Elena de Vega Gil


TEL: (+34) 91 353 15 64

FAX: (+34) 91 359 61 79

E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.







Metodos Y Tecnología (MTP)

Paseo de la Castellana 182, 10

28046 Madrid, España

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members
only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
Enviado el: jueves, 25 de septiembre de 2008 14:05
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Uniqueness of identifiers

Dear all,

is the following type definition allowed if A, B and C are
already used as identifiers for other types?

type record sample_record_type {
A A,
B B,
C C
}

This is possible because you can have a subtype field with the
same name that its type. The type and the field have different
scope then there are not problem.

The core spec (3.4.1) says in 5.2.2:

"TTCN-3 requires uniqueness of identifiers, i.e. all
identifiers in the same scope hierarchy shall be distinctive.
This means that a declaration in a lower level of scope shall
not re-use the same identifier as a declaration in a higher
level of scope in the same branch of the scope hierarchy.
Identifiers for fields of structured types, enumeration values
and groups do not have to be globally unique, however in the
case of enumeration values the identifiers shall only be
reused for enumeration values within other enumerated types."

In my understanding the identifiers of enumeration values may
only be reused for other enumeration values. Does a similar
restriction apply for fields of structured types or is it
allowed to reuse the identifiers of fields of structured types
e. g. for other type names? Are there any details or examples
in the spec on this?

Thanks in advance and regards,

Corinna

---

---

Corinna Wiegert
Rohde & Schwarz GmbH & Co. KG
Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
81614 München / GERMANY

Tel: +49-89-4129-13498
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Web: www.rohde-schwarz.com

---

---

=











--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Jacob and others,

I'm not yet convinced by the arguments provided so far.
Please find my arguments below. And sure, I would also prefer that my arguments are flawed instead of the standard being inconsistent :-)

Please consider the following more as an analysis of what the standard defines. I would not object to clarify the standard such that the understanding of Jacob, Ivan, Elena, and other is clearly expressed within the standard.

Best regards

Thomas


________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext Jacob Wieland
Sent: Thursday, 25. September 2008 17:32
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Thomas,

I disagree, I think the example is totally valid.

Record 'scopes' are not scope units as statement blocks or the module body.


I agree, record type definitions are not scope units. From the seven scope units listed in clause 5.2, two are relevant regarding this issue: module definitions part and component types. Note that it is only component types that are a scope unit, but not other type definitions.

Clause 5.2.2 presents the requirements on uniqueness of identifiers.

"TTCN‑3 requires uniqueness of identifiers, i.e. all identifiers in the same scope hierarchy shall be distinctive. "
So, clearly the following is incorrect (two type definitions with the same name).
type record R {integer a};
type record R {integer b};
I think we all agree on this.

Then we have
"This means that a declaration in a lower level of scope shall not re-use the same identifier as a declaration in a higher level of scope in the same branch of the scope hierarchy."
For a component type definition, which is a new scope unit itself, this means that the element names in the component type cannot reuse identifiers from the module.
type record S {integer a};
const integer c := 1;
type component CT {
var boolean S;
var integer c
}
For the element named S, an identifier of the higher scope unit is reused. And the same holds for the element named c.
Note that it does not make a difference whether the reused identifier is from a type or some other definition.
Clause 6.2.10.1 only states that port names are local to the component type. Timers, variables, and constants are not mentioned. Therefore, I do not see that the standard allows exceptions to not allowing reuse of identifiers on module level.
Note also that the elements of a component type are accessed without using the dot notation.
Note also that this rule disallows the use of identifiers on module level as names of local variables, constants, etc. within functions, etc.

Now the critical statement:
"Identifiers for fields of structured types, enumeration values and groups do not have to be globally unique, however in the case of enumeration values the identifiers shall only be reused for enumeration values within other enumerated types"
And let me add the corresponding sentence from clause 6.2.1 (thanks Gyorgy!), a similar statement exists for set types.
"The element identifiers are local to the record and shall be unique within the record (but do not have to be globally unique). "
the corresponding from clause 6.2.4 for enumerations.
"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. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy "
and also the corresponding sentence from clause 6.2.10.1
"The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names. Port names in the same component type definition shall all have unique names."
There is no corresponding exception for union types in clause 6.2.5. Actually I think the different alternatives in unions should just be handled as the field names of records.

This problem boils down to how 'globally unique' shall be understood. It is stated that field names do not have to be globally unique. For me it is not clear that this allows to reuse the name of global definitions, the uniqueness of the identifier used on the module level has not been relaxed. I simply don't see this.

There is no conflict as these names can only be used
on the left hand side of a field assignment or on the right hand side of a dot. Thus, they can never be confused with names declared
in the same scope. The only restriction is that inside the same record/set 'scope', the field names must be unique to avoid
nameclashes between them.


The possibility to refer to the type of a record field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}



I also think that that is what the standard describes when referencing the exception of field names which Elena quoted.

If your reasoning were true, then it should also not be possible to introduce a record with a field f which is itself again
a record with field f. But, since the first field f could also have a record type with a field f which was declared in a different module,
this would have to be disallowed as well (even though in both cases there is no name conflict anywhere), but isn't.


Good point. Obviously this has to be allowed. Without nested type definitions this is not a problem. But also in the case of nested type definitions this has to be allowed.



Thus, either your reasoning is flawed or the standard is inconsistent. In this instant, I vote the former ;-)

Best regards,

Jacob Wieland

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Elena and Corinna,

It's my understanding that Corinna's example is invalid. The same identifier has been used twice in the same scope unit (the module), once as identifier of a type and once as identifier of a field.

Regarding uniqueness of fieldnames of different record types and of enumeration values.

type record R1 { integer a, boolean b};
type record R2 { integer a, boolean b};
type enumerated E1 {c};

would be ok. What's not ok is to define in addition:

type enumerated E2 { b, c };

The identifier b can be used only as an enumeration value. But it is also used as fieldname of a record. The definition of the enumeration value c in both enumerations E1 and E2 is fine.

That's my understanding of clause 5.2.2.

Hope this helps ... stimulates discussion to clarify this issue. Seems that the standards leaves room for interpretation.

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
Elena de Vega
Sent: Thursday, 25. September 2008 16:15
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers

Hi Corinna,

Your example is possible because you can have a subtype field
with the same name that its type. The type and the field have
different scope then there is no problem.

type record sample_record_type {
A A,
B B,
C C
}



The enumerated types:

There isn't the same restriction for structured types; it's
only for enumerated types.
You can see enumerated examples on the page 41 (core v3.4.1).


Elena de Vega Gil


TEL: (+34) 91 353 15 64

FAX: (+34) 91 359 61 79

E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it.







Metodos Y Tecnología (MTP)

Paseo de la Castellana 182, 10

28046 Madrid, España

---

Mensaje original

---

De: active_ttcn3 : mts stf133 ttcn version 3 - active members
only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
Enviado el: jueves, 25 de septiembre de 2008 14:05
Para: This email address is being protected from spambots. You need JavaScript enabled to view it.
Asunto: Uniqueness of identifiers

Dear all,

is the following type definition allowed if A, B and C are
already used as identifiers for other types?

type record sample_record_type {
A A,
B B,
C C
}

This is possible because you can have a subtype field with the
same name that its type. The type and the field have different
scope then there are not problem.

The core spec (3.4.1) says in 5.2.2:

"TTCN-3 requires uniqueness of identifiers, i.e. all
identifiers in the same scope hierarchy shall be distinctive.
This means that a declaration in a lower level of scope shall
not re-use the same identifier as a declaration in a higher
level of scope in the same branch of the scope hierarchy.
Identifiers for fields of structured types, enumeration values
and groups do not have to be globally unique, however in the
case of enumeration values the identifiers shall only be
reused for enumeration values within other enumerated types."

In my understanding the identifiers of enumeration values may
only be reused for other enumeration values. Does a similar
restriction apply for fields of structured types or is it
allowed to reuse the identifiers of fields of structured types
e. g. for other type names? Are there any details or examples
in the spec on this?

Thanks in advance and regards,

Corinna

---

---

Corinna Wiegert
Rohde & Schwarz GmbH & Co. KG
Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
81614 München / GERMANY

Tel: +49-89-4129-13498
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Web: www.rohde-schwarz.com

---

---

=








--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

I'm pretty sure that Claude confused the order type/fieldname with the
order in ASN.1 and meant:
field-names A, B, C, D, with types A, B, C, C, respectively. Then, his
argument would make sense,
otherwise, I have to agree With György ;-)

BR, Jacob

György Réthy wrote:
> Hi Claude,
>
> Your analysis, unfortunately, is incorrect.
> "
> type record sample_record_type { // this type is illegal.
> A A,
> B B,
> C C,
> C D // TTCN-3 requires uniqueness of identifiers within the same
> "
> is perfectly legal. the standard says in $6.2.1: "The element
> identifiers are local to the *record* and shall be unique within the
> *record* (but do not have to be globally unique).
> " The element identifiers are A,B,C and D, they are unique. Dont mix element identifiers by the type of the elements. In all references (value notations, template definitions, just referring a field etc.) only the element identifiers are used, never their type.
>
> BR, Gyorgy
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Claude Desroches
> *Sent:* 2008. szeptember 25. 20:20
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Uniqueness of identifiers
>
> Hi Everyone,
>
>
>
> Corinna's and Jacob's analysis are correct.
>
>
>
>
>
> type record sample_record_type { // this type is completely legal.
>
> A A,
>
> B B,
>
> C C
>
> }
>
>
>
> type record sample_record_type { // this type is illegal.
>
> A A,
>
> B B,
>
> C C,
>
> C D // TTCN-3 requires uniqueness of identifiers within the same
>
> // scope branch as well as within a given record or set.
>
> // If this were legal, there would need to be a way to determine
>
> // which C is being referenced. In the case of template definition
>
> // field ordering can be used to determine this, but in an assignment
>
> // this would only be possible by tagging the field with its type.
>
>
>
> // It just easier to avoid such things to start with.
>
> }
>
>
>
>
>
> Whichever the case, I would not recommend defining records where
> the field name and the field type is the same. Even if it is
> allowed, its simply asking for trouble. Why would someone want
> to create such needless confusion???
>
>
>
> Just my two cents for this evening. J
>
>
>
>
>
>
>
>
>
> Claude.
>
>
>
> BluKaktus Communications phone: +49 (0)30 9606 7985
>
> Edinburger Str. 39 fax: +49 (0)30 9606 7987
>
> 13349 Berlin mobile: +49 (0)174 701 6792
>
> Germany email: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
>
>
>

---

>
> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Jacob Wieland
> *Sent:* September 25, 2008 5:32 PM
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Uniqueness of identifiers
>
>
>
> Hello Thomas,
>
> I disagree, I think the example is totally valid.
>
> Record 'scopes' are not scope units as statement blocks or the
> module body. There is no conflict as these names can only be used
> on the left hand side of a field assignment or on the right hand
> side of a dot. Thus, they can never be confused with names declared
> in the same scope. The only restriction is that inside the same
> record/set 'scope', the field names must be unique to avoid
> nameclashes between them.
>
> I also think that that is what the standard describes when
> referencing the exception of field names which Elena quoted.
>
> If your reasoning were true, then it should also not be possible
> to introduce a record with a field f which is itself again
> a record with field f. But, since the first field f could also
> have a record type with a field f which was declared in a
> different module,
> this would have to be disallowed as well (even though in both
> cases there is no name conflict anywhere), but isn't.
>
> Thus, either your reasoning is flawed or the standard is
> inconsistent. In this instant, I vote the former ;-)
>
> Best regards,
>
> Jacob Wieland
>
> Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
>
> Hello Elena and Corinna,
>
>
>
> It's my understanding that Corinna's example is invalid. The same identifier has been used twice in the same scope unit (the module), once as identifier of a type and once as identifier of a field.
>
>
>
> Regarding uniqueness of fieldnames of different record types and of enumeration values.
>
>
>
> type record R1 { integer a, boolean b};
>
> type record R2 { integer a, boolean b};
>
> type enumerated E1 {c};
>
>
>
> would be ok. What's not ok is to define in addition:
>
>
>
> type enumerated E2 { b, c };
>
>
>
> The identifier b can be used only as an enumeration value. But it is also used as fieldname of a record. The definition of the enumeration value c in both enumerations E1 and E2 is fine.
>
>
>
> That's my understanding of clause 5.2.2.
>
>
>
> Hope this helps ... stimulates discussion to clarify this issue. Seems that the standards leaves room for interpretation.
>
>
>
> Best regards
>
>
>
> Thomas
>
>
>
>

---

|
>
> | Thomas Deiß |
>
> | Nokia Siemens Networks |
>
> | Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
>
> | Internal: 828 3584 |
>
> | Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
>
> | email: This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.> |
>
>

---

|
>
>
>
>
>
>
>
>>

---

Original Message

---

>> From: active_ttcn3 : mts stf133 ttcn version 3 - active
>> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>> Elena de Vega
>> Sent: Thursday, 25. September 2008 16:15
>> To: This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>> Subject: Re: Uniqueness of identifiers
>>
>> Hi Corinna,
>>
>> Your example is possible because you can have a subtype field
>> with the same name that its type. The type and the field have
>> different scope then there is no problem.
>>
>> type record sample_record_type {
>> A A,
>> B B,
>> C C
>> }
>>
>>
>>
>> The enumerated types:
>>
>> There isn't the same restriction for structured types; it's
>> only for enumerated types.
>> You can see enumerated examples on the page 41 (core v3.4.1).
>>
>>
>> Elena de Vega Gil
>>
>>
>> TEL: (+34) 91 353 15 64
>>
>> FAX: (+34) 91 359 61 79
>>
>> E-MAIL: This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>>
>>
>>
>>
>>
>>
>>
>> Metodos Y Tecnología (MTP)
>>
>> Paseo de la Castellana 182, 10
>>
>> 28046 Madrid, España
>>
>>
>>
>>
>>

---

Mensaje original

---

>> De: active_ttcn3 : mts stf133 ttcn version 3 - active members
>> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] En nombre de Corinna Wiegert
>> Enviado el: jueves, 25 de septiembre de 2008 14:05
>> Para: This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>> Asunto: Uniqueness of identifiers
>>
>> Dear all,
>>
>> is the following type definition allowed if A, B and C are
>> already used as identifiers for other types?
>>
>> type record sample_record_type {
>> A A,
>> B B,
>> C C
>> }
>>
>> This is possible because you can have a subtype field with the
>> same name that its type. The type and the field have different
>> scope then there are not problem.
>>
>> The core spec (3.4.1) says in 5.2.2:
>>
>> "TTCN-3 requires uniqueness of identifiers, i.e. all
>> identifiers in the same scope hierarchy shall be distinctive.
>> This means that a declaration in a lower level of scope shall
>> not re-use the same identifier as a declaration in a higher
>> level of scope in the same branch of the scope hierarchy.
>> Identifiers for fields of structured types, enumeration values
>> and groups do not have to be globally unique, however in the
>> case of enumeration values the identifiers shall only be
>> reused for enumeration values within other enumerated types."
>>
>> In my understanding the identifiers of enumeration values may
>> only be reused for other enumeration values. Does a similar
>> restriction apply for fields of structured types or is it
>> allowed to reuse the identifiers of fields of structured types
>> e. g. for other type names? Are there any details or examples
>> in the spec on this?
>>
>> Thanks in advance and regards,
>>
>> Corinna
>>
>>
>>

---

>>

---

>> Corinna Wiegert
>> Rohde & Schwarz GmbH & Co. KG
>> Test and Measurement Division, Dept. 1SP4 P.O. Box 80 14 69
>> 81614 München / GERMANY
>>
>> Tel: +49-89-4129-13498
>> Email: This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>> Web: www.rohde-schwarz.com
>>

---

>>

---

=
>>
>>
>
>
>
>
>
>
>
> --
>
>

---

>
> Jacob Wieland
>
> Software Engineer
>
>
>
> Testing Technologies IST GmbH
>
> Michaelkirchstraße 17/18
>
> 10179 Berlin, Germany
>
>
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.>
>
> Fax +49 30 726 19 19 20 Internet www.testingtech.com <www.testingtech.com>
>
>

---

>
>
>
> UPCOMING EVENTS!
>
>
>
> September 24-26, Conquest, Booth #004
>
> Potsdam, Germany
>
> www.isqi.org/konferenzen/conquest/2008/ <www.isqi.org/konferenzen/conquest/2008/>
>
>
>
> September 27, ASQF Golf Cup
>
> Potsdam, Germany
>
> www.asqf.de/veranstaltungen/4-asqf-golf-cup/ <www.asqf.de/veranstaltungen/4-asqf-golf-cup/>
>
>
>
> October 15, Free Webinar "TTCN-3 for Test Automation"
>
> www.testingtech.com/services/ttcn3_webinar.php <www.testingtech.com/services/ttcn3_webinar.php>
>
>
>
>

---

>
> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
>
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
>
> Ust ID Nr.: DE 813 143 070
>
>
>
> This e-mail may contain confidential and privileged material for the
>
> sole use of the intended recipient. Any review, use, distribution or
>
> disclosure by others is strictly prohibited. If you are not the intended
>
> recipient (or authorized to receive for the recipient), please contact
>
> the sender by reply e-mail and delete all copies of this message.
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
> Hello Jacob and others,
>
> I'm not yet convinced by the arguments provided so far.
> Please find my arguments below. And sure, I would also prefer that my
> arguments are flawed instead of the standard being inconsistent :-)
>
> Please consider the following more as an analysis of what the standard
> defines. I would not object to clarify the standard such that the
> understanding of Jacob, Ivan, Elena, and other is clearly expressed
> within the standard.
>
I think it already is stated (with the exception of unions that you
found) clearly enough already, but more clarity, as long as our
understanding does not change will probably not hurt.

See my other comments inline.
>
>
> Record 'scopes' are not scope units as statement blocks or the
> module body.
>
>
> I agree, record type definitions are not scope units. From the seven
> scope units listed in clause 5.2, two are relevant regarding this
> issue: module definitions part and component types. Note that it is
> only component types that are a scope unit, but not other type
> definitions.
>
> Clause 5.2.2 presents the requirements on uniqueness of identifiers.
>
> "TTCN‑3 requires uniqueness of identifiers, i.e. all identifiers in
> the same scope hierarchy shall be distinctive. "
> So, clearly the following is incorrect (two type definitions with the
> same name).
> type record R {integer a};
> type record R {integer b};
> I think we all agree on this.
I agree.
>
> Then we have
> "This means that a declaration in a lower level of scope shall not
> re-use the same identifier as a declaration in a higher level of scope
> in the same branch of the scope hierarchy."
> For a component type definition, which is a new scope unit itself,
> this means that the element names in the component type cannot reuse
> identifiers from the module.
> type record S {integer a};
> const integer c := 1;
> type component CT {
> var boolean S;
> var integer c
> }
> For the element named S, an identifier of the higher scope unit is
> reused. And the same holds for the element named c.
> Note that it does not make a difference whether the reused
> identifier is from a type or some other definition.
> Clause 6.2.10.1 only states that port names are local to the component
> type. Timers, variables, and constants are not mentioned. Therefore, I
> do not see that the standard allows exceptions to not allowing reuse
> of identifiers on module level.
> Note also that the elements of a component type are accessed without
> using the dot notation.
> Note also that this rule disallows the use of identifiers on module
> level as names of local variables, constants, etc. within functions, etc.
>
> Now the critical statement:
> "Identifiers for fields of structured types, enumeration values and
> groups do not have to be globally unique, however in the case of
> enumeration values the identifiers shall only be reused for
> enumeration values within other enumerated types"
> And let me add the corresponding sentence from clause 6.2.1 (thanks
> Gyorgy!), a similar statement exists for set types.
> "The element identifiers are local to the *record* and shall be unique
> within the *record* (but do not have to be globally unique). "
> the corresponding from clause 6.2.4 for enumerations.
> "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. Enumeration identifiers
> shall only be reused within other structured type definitions and
> shall not be used for identifiers of local or global visibility at the
> same or a lower level of the same branch of the scope hierarchy "
> and also the corresponding sentence from clause 6.2.10.1
> "The port names in a component type definition are local to that
> component type, i.e. another component type may have ports with the
> same names. Port names in the same component type definition shall all
> have unique names."
> There is no corresponding exception for union types in clause 6.2.5.
> Actually I think the different alternatives in unions should just be
> handled as the field names of records.
I agree.
>
> This problem boils down to how 'globally unique' shall be understood.
> It is stated that field names do not have to be globally unique. For
> me it is not clear that this allows to reuse the name of global
> definitions, the uniqueness of the identifier used on the module level
> has not been relaxed. I simply don't see this.
I think the reason is this: since record 'scopes' are not actually
scopes and thus not part of any 'scope hierarchy', their field
identifiers do not clash with names in the scope hierarchy and there is
no relaxation of the property that names in the scope hierarchy have to
be globally unique.
>
> There is no conflict as these names can only be used
> on the left hand side of a field assignment or on the right hand
> side of a dot. Thus, they can never be confused with names declared
> in the same scope. The only restriction is that inside the same
> record/set 'scope', the field names must be unique to avoid
> nameclashes between them.
>
>
> The possibility to refer to the type of a record field creates an
> interesting puzzle. What's the type of the field V.d: boolean or integer?
> type record U { integer T };
> type record V {
> record {boolean T} U,
> U.T d
> }
I think V.d must be integer, because you cannot refer to other fields in
the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could never be disambiguated
via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is integer.

Best regards,

Jacob

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Jacob,

let me just restrict for the moment to the example with the type reference. Please find my comment below.

best regards

Thomas

---

| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21 |
| D-40472 Düsseldorf |
| Mobile: +49 1639842217 |
| internal: 827 2217 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

<--- snip, TD --->

The possibility to refer to the type of a record field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}

I think V.d must be integer, because you cannot refer to other fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could never be disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is integer.


Note that U in the field definition 'record {boolean T} U' is not the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.
Why should it not be possible to refer to types of fields of the same record?
type record X {
record of boolean b;
X.b c
}
should be ok, isn't it?



Best regards,

Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

<--- snip, TD --->

Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
> Hello Jacob,
>
> let me just restrict for the moment to the example with the type
> reference. Please find my comment below.
Same here ;-)
>
> <--- snip, TD --->
>> The possibility to refer to the type of a record field creates an
>> interesting puzzle. What's the type of the field V.d: boolean or
>> integer?
>> type record U { integer T };
>> type record V {
>> record {boolean T} U,
>> U.T d
>> }
> I think V.d must be integer, because you cannot refer to other
> fields in the type of the declaration of a field (because of the
> rule that these
> names need not be disjoint and therefore could never be
> disambiguated via a prefix), but only to globally declared types.
> Thus, U.T must mean field T of type U, which is integer.
>
>
> Note that U in the field definition 'record {boolean T} U' is not the
> name of a type, which does not have to be unique as you correctly
> observe. U is the name of a field, and this has to be unique within V.
I have noted. U is both the name of a type and the name of a record
field. Since it is not possible to reference the record field without
using the type prefix (V.U in your example), the reference 'U' in 'U.T
d' must mean the type U, not the field U.
> Why should it not be possible to refer to types of fields of the same
> record?
Of course it is possible, but not without the explicit type prefix, as
field names can only be referenced relative to something.
> type record X {
> record of boolean b;
> X.b c
> }
> should be ok, isn't it?
Yes, here you correctly reference the field b by using the type prefix X.

BR, Jacob
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> <--- snip, TD --->
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi,

This discussion starts to become a hard-to-follow to me, so I will try to sum up what is allowed acc. to the standard and what is not.

1) Field names of record and set types and names of alternatives in union types:
shall be unique among the other field/alternative names of the given type only; i.e. may be the same as field/alternative/enumeration names in any other structured types and may be the same as the name of any global or local definition.
i.e., allowed:
type integer A;
type integer B;
type integer C;
type record D {
A A,
B B,
C C,
D D optional, //optional is a must here because of the recursive reference
C E
}
type record E {
C C,
D.E c
// ^ pls. note, any dot reference shall start with the module or global definition name
}
type component CT {
const integer c := 0
}

function F() {
const integer c := 0;
}

and this is not allowed:
type record E {
integer C,
octetstring C
}

2) Enumeration names in enumerated types:
Shall be unique within the type and may be identical as enumeration names in other enumerated types; but shall not clash with any other global or local names.
i.e. allowed:
type enumerated Enum1 { e1, e2, e3 }
type enumerated Enum2 { e1, e2, e3 }
type record R {
Enum1 e1,
Enum2 e2
}

and these are not allowed:
type enumerated Enum3 { e11, e21, e31 }
const integer e11 := 0;
type integer e21;
type component CT {
var integer e31;
}
function F() {
var Enum2 e21
}

3) The rest:
I suppose it should be rather clear, the scoping rules apply. Global names shall be unique and local names shall be different from global names, local names in a higher scope (i.e. local var name of a function with a runs on clause shall differ from the names in the comp. type definition) and other names in the same scope. Pls. note, there is no specific rules/exceptions e.g. for port instance names; ports in different component types are always in different scope units as component types are always global definitions. So, the sentence "The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names." is just drawing the attention to something that is the outcome of the scoping rules anyway.
i.e. these are allowed:
type component CT {
const integer ci := 0;
port PT P1;
port PT P2
}
type component CTx {
port PT P1
}

function F1() {
const integer ci := 0;
}

function F2() {
const integer ci := 0;
}

but these are not:

---

type component CT1 {
const integer ci := 0;
}

function F() runs on CT1 {
const integer ci := 0;
}

---

type component CT2 {
port PT P
port PT P;
}

---

type integer I;
function F() {
var integer I
}

---

BR, Gyorgy

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 11:03
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Jacob,

let me just restrict for the moment to the example with the type reference. Please find my comment below.

Same here ;-)





<--- snip, TD --->

The possibility to refer to the type of a record field
creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}

I think V.d must be integer, because you cannot refer to other
fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could never be
disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is integer.


Note that U in the field definition 'record {boolean T} U' is not
the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.

I have noted. U is both the name of a type and the name of a record field. Since it is not possible to reference the record field without using the type prefix (V.U in your example), the reference 'U' in 'U.T d' must mean the type U, not the field U.


Why should it not be possible to refer to types of fields of the
same record?


Of course it is possible, but not without the explicit type prefix, as field names can only be referenced relative to something.


type record X {
record of boolean b;
X.b c
}

should be ok, isn't it?

Yes, here you correctly reference the field b by using the type prefix X.

BR, Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

<--- snip, TD --->



--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hello Gyorgy,

In my opinion example 2 is not correct. The enumeration values are used also as field names within a record type, but clause 5.2.2 states "in the case of enumeration values the identifiers shall only be reused for enumeration values within other enumerated types" How does this fit together? What am I getting wrong?

Best regards

Thomas



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 26. September 2008 12:55
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hi,

This discussion starts to become a hard-to-follow to me, so I will try to sum up what is allowed acc. to the standard and what is not.

1) Field names of record and set types and names of alternatives in union types:
shall be unique among the other field/alternative names of the given type only; i.e. may be the same as field/alternative/enumeration names in any other structured types and may be the same as the name of any global or local definition.
i.e., allowed:
type integer A;
type integer B;
type integer C;
type record D {
A A,
B B,
C C,
D D optional, //optional is a must here because of the recursive reference
C E
}

type record E {
C C,
D.E c
// ^ pls. note, any dot reference shall start with the module or global definition name
}
type component CT {
const integer c := 0
}

function F() {
const integer c := 0;
}

and this is not allowed:

type record E {
integer C,
octetstring C
}

2) Enumeration names in enumerated types:
Shall be unique within the type and may be identical as enumeration names in other enumerated types; but shall not clash with any other global or local names.
i.e. allowed:
type enumerated Enum1 { e1, e2, e3 }

type enumerated Enum2 { e1, e2, e3 }
type record R {
Enum1 e1,
Enum2 e2
}


and these are not allowed:
type enumerated Enum3 { e11, e21, e31 }
const integer e11 := 0;
type integer e21;
type component CT {
var integer e31;
}
function F() {

var Enum2 e21
}

3) The rest:
I suppose it should be rather clear, the scoping rules apply. Global names shall be unique and local names shall be different from global names, local names in a higher scope (i.e. local var name of a function with a runs on clause shall differ from the names in the comp. type definition) and other names in the same scope. Pls. note, there is no specific rules/exceptions e.g. for port instance names; ports in different component types are always in different scope units as component types are always global definitions. So, the sentence "The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names." is just drawing the attention to something that is the outcome of the scoping rules anyway.
i.e. these are allowed:

type component CT {
const integer ci := 0;
port PT P1;
port PT P2
}
type component CTx {
port PT P1
}

function F1() {
const integer ci := 0;
}


function F2() {
const integer ci := 0;
}

but these are not:

---

type component CT1 {
const integer ci := 0;
}

function F() runs on CT1 {
const integer ci := 0;
}

---

type component CT2 {
port PT P
port PT P;
}

---

type integer I;
function F() {
var integer I
}

---

BR, Gyorgy

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 11:03
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Jacob,

let me just restrict for the moment to the example with the
type reference. Please find my comment below.

Same here ;-)





<--- snip, TD --->

The possibility to refer to the type of a record
field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}

I think V.d must be integer, because you cannot refer to
other fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could never be
disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is
integer.


Note that U in the field definition 'record {boolean T} U' is
not the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.

I have noted. U is both the name of a type and the name of a record
field. Since it is not possible to reference the record field without using the type prefix (V.U in your example), the reference 'U' in 'U.T d' must mean the type U, not the field U.


Why should it not be possible to refer to types of fields of
the same record?


Of course it is possible, but not without the explicit type prefix,
as field names can only be referenced relative to something.


type record X {
record of boolean b;
X.b c
}

should be ok, isn't it?

Yes, here you correctly reference the field b by using the type
prefix X.

BR, Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

<--- snip, TD --->



--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email
This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this message.

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
> Hello Gyorgy,
>
> In my opinion example 2 is not correct. The enumeration values are
> used also as field names within a record type, but clause 5.2.2 states
> "in the case of enumeration values the identifiers shall only be
> reused for enumeration values within other enumerated types" How does
> this fit together? What am I getting wrong?
>
I think what is MEANT here is that they shall not be used as 'scoped
names' except for other enumeration values. Scoped names being those in
the scope hierarchy, not those of field declarations.

Maybe this should be clarified.

BR, Jacob
> Best regards
>
> Thomas
>
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active members
> only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *ext György Réthy
> *Sent:* Friday, 26. September 2008 12:55
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Uniqueness of identifiers
>
> Hi,
>
> This discussion starts to become a hard-to-follow to me, so I will
> try to sum up what is allowed acc. to the standard and what is not.
>
> 1) Field names of record and set types and names of
> alternatives in union types:
> shall be unique among the other field/alternative names of the
> given type only; i.e. may be the same as
> field/alternative/enumeration names in any other structured types
> and may be the same as the name of any global or local definition.
> i.e., allowed:
> *type* *integer* A;
> *type* *integer* B;
> *type* *integer* C;
> *type* *record* * *D {
> A A,
> B B,
> C C,
> D D *optional*, //optional is a must here because of
> the recursive reference
> C E
> }
> *type* *record* * *E {
> C C,
> D.E c
> // ^ pls. note, any dot reference shall start with the module or
> global definition name
> }
> *type component* CT {
> *const integer* c := 0
> }
>
> *function* F() {
> * **const integer* c := 0;
> }
>
> and this is not allowed:
> *type* *record* * *E {
> integer C,
> octetstring C
> }
>
> 2) Enumeration names in enumerated types:
> Shall be unique within the type and may be identical as
> enumeration names in other enumerated types; but shall not clash
> with any other global or local names.
> i.e. allowed:
> *type enumerated* Enum1 { e1, e2, e3 }
> *type enumerated* Enum2 { e1, e2, e3 }
> *type record* R {
> Enum1 e1,
> Enum2 e2
> }
>
> and these are not allowed:
> *type enumerated* Enum3 { e11, e21, e31 }
> *const* *integer* e11 := 0;
> *type integer* e21;
> *type component* CT {
> *var* *integer* e31;
> }
> *function* F() {
> *var* Enum2 e21
> }
>
> 3) The rest:
> I suppose it should be rather clear, the scoping rules apply.
> Global names shall be unique and local names shall be different
> from global names, local names in a higher scope (i.e. local var
> name of a function with a runs on clause shall differ from the
> names in the comp. type definition) and other names in the same
> scope. Pls. note, there is no specific rules/exceptions e.g. for
> port instance names; ports in different component types are always
> in different scope units as component types are always global
> definitions. So, the sentence "The port names in a component type
> definition are local to that component type, i.e. another
> component type may have ports with the same names." is just
> drawing the attention to something that is the outcome of the
> scoping rules anyway.
> i.e. these are allowed:
> *type component* CT {
> *const integer* ci := 0;
> *port* PT P1;
> *port* PT P2
> }
> *type component* CTx {
> *port* PT P1
> }
>
> *function* F1() {
> * **const integer* ci := 0;
> }
>
> *function* F2() {
> * **const integer* ci := 0;
> }
>
> but these are not:
> *

---

*
> *type component* CT1 {
> *const integer* ci := 0;
> }
>
> *function* F() *runs on* CT1 {
> * **const integer* ci := 0;
> }
> *

---

*
> *type component* CT2 {
> *port* PT P
> *port* PT P;
> }
> *

---

*
> *type integer* I;
> *function* F() {
> *var integer* I
> }
> *

---

*
> BR, Gyorgy
>
>

---

> *From:* active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] *On Behalf Of *Jacob
> Wieland
> *Sent:* 2008. szeptember 26. 11:03
> *To:* This email address is being protected from spambots. You need JavaScript enabled to view it.
> *Subject:* Re: Uniqueness of identifiers
>
> Hello Thomas,
>
> Deiss, Thomas (NSN - DE/Duesseldorf) wrote:
>> Hello Jacob,
>>
>> let me just restrict for the moment to the example with the
>> type reference. Please find my comment below.
> Same here ;-)
>>
>> <--- snip, TD --->
>>> The possibility to refer to the type of a record field
>>> creates an interesting puzzle. What's the type of the
>>> field V.d: boolean or integer?
>>> type record U { integer T };
>>> type record V {
>>> record {boolean T} U,
>>> U.T d
>>> }
>> I think V.d must be integer, because you cannot refer to
>> other fields in the type of the declaration of a field
>> (because of the rule that these
>> names need not be disjoint and therefore could never be
>> disambiguated via a prefix), but only to globally
>> declared types.
>> Thus, U.T must mean field T of type U, which is integer.
>>
>>
>> Note that U in the field definition 'record {boolean T} U' is
>> not the name of a type, which does not have to be unique as
>> you correctly observe. U is the name of a field, and this has
>> to be unique within V.
> I have noted. U is both the name of a type and the name of a
> record field. Since it is not possible to reference the record
> field without using the type prefix (V.U in your example), the
> reference 'U' in 'U.T d' must mean the type U, not the field U.
>> Why should it not be possible to refer to types of fields of
>> the same record?
> Of course it is possible, but not without the explicit type
> prefix, as field names can only be referenced relative to
> something.
>> type record X {
>> record of boolean b;
>> X.b c
>> }
>> should be ok, isn't it?
> Yes, here you correctly reference the field b by using the
> type prefix X.
>
> BR, Jacob
>>
>> --
>>

---

>> Jacob Wieland
>> Software Engineer
>>
>> Testing Technologies IST GmbH
>> Michaelkirchstraße 17/18
>> 10179 Berlin, Germany
>>
>> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
>> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>>

---

>>
>> <--- snip, TD --->
>>
>
>
> --
>

---

> Jacob Wieland
> Software Engineer
>
> Testing Technologies IST GmbH
> Michaelkirchstraße 17/18
> 10179 Berlin, Germany
>
> Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
> Fax +49 30 726 19 19 20 Internet www.testingtech.com
>

---

>
> UPCOMING EVENTS!
>
> September 24-26, Conquest, Booth #004
> Potsdam, Germany
> www.isqi.org/konferenzen/conquest/2008/
>
> September 27, ASQF Golf Cup
> Potsdam, Germany
> www.asqf.de/veranstaltungen/4-asqf-golf-cup/
>
> October 15, Free Webinar "TTCN-3 for Test Automation"
> www.testingtech.com/services/ttcn3_webinar.php
>
>

---

> Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
> Handelsregister HRB 77805, Amtsgericht Charlottenburg
> Ust ID Nr.: DE 813 143 070
>
> This e-mail may contain confidential and privileged material for the
> sole use of the intended recipient. Any review, use, distribution or
> disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact
> the sender by reply e-mail and delete all copies of this message.
>
>


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

hi,

I have a couple of notions about the descriptions used in the scoping rules. I'd like to state them with the reasoning that the more straightforward the specification, the lower the learning threshold, introduction to, and usage of TTCN-3 is. Also, I'd like to also help myself follow the discussion easier in the future...

* The examples about using a field identifier as a type reference I think should not be valid, as the field name denotes a feature of the type, not a type (Resolving using the type of an expression is a different case). I would judge it like this because in general one might declare types within types, if the declaration rules allow it. When the declaration rules do not allow declaring types within types, there should be no reason to try to have a name lookup for types resolve a reference within a type definition to another field of the same type. When resolving type identifiers used in type definitions according to the visibility rules (trying to get to the scope of visibility of the identifier being resolved) the first scope attempted should be the scope of the type. Then if a particular field type must absolutely be used, it should be declared as a type.

* The second is the example of overloading a type identifier with a field name. I don't think this is really usable, while it might be an interesting experiment, it does not in my opinion serve a purpose where overloading is commonly used. However, if describing types to be declaration scopes, one could say that the matching field expression hides the identifier of the field's type, which would be consistent with their usage in name lookup by visibility rules normally. If overloading is the alternative used, there should also be rules on the resolving of the overloading if the expressions of this type may contain both references to the field types and to the fields.

* Thirdly, it should be accepted that in expressions, visibility rules include name lookup by the type of the expression is used (and allow overloading of identifiers more freely). Other than lexical scopes are already used, as I think function bodies already have component types as their scopes, why not allow types to be the scopes of expressions of the type. I think then it might be possible to remove the restrictions of the enumeration identifiers.

* Lastly, I think it's the language user's choice to hide an identifier if they please (and I may contradict myself here). I think identifiers hiding other identifiers should not be restricted in a global scope, because that will only result in compilation problems when creating new programs. Any accidental matches will be reported by type resolving of expressions.

I don't know if this is applicable to the current language specification, as backward compatibility should be preserved; Starting to use scopes as types might add a dimension to the visibility rules, but I'd still make the same arguments as I think the scoping rules should be easier to read.

Best regards,

Martti Söderlund, Specialist Software Engineer

TietoEnator Telecom & Media


________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Deiss, Thomas (NSN - DE/Duesseldorf)
Sent: 26. syyskuuta 2008 14:15
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Gyorgy,

In my opinion example 2 is not correct. The enumeration values are used also as field names within a record type, but clause 5.2.2 states "in the case of enumeration values the identifiers shall only be reused for enumeration values within other enumerated types" How does this fit together? What am I getting wrong?

Best regards

Thomas



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 26. September 2008 12:55
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hi,

This discussion starts to become a hard-to-follow to me, so I will try to sum up what is allowed acc. to the standard and what is not.

1) Field names of record and set types and names of alternatives in union types:
shall be unique among the other field/alternative names of the given type only; i.e. may be the same as field/alternative/enumeration names in any other structured types and may be the same as the name of any global or local definition.
i.e., allowed:
type integer A;
type integer B;
type integer C;
type record D {
A A,
B B,
C C,
D D optional, //optional is a must here because of the recursive reference
C E
}
type record E {
C C,
D.E c
// ^ pls. note, any dot reference shall start with the module or global definition name
}
type component CT {
const integer c := 0
}

function F() {
const integer c := 0;
}

and this is not allowed:
type record E {
integer C,
octetstring C
}

2) Enumeration names in enumerated types:
Shall be unique within the type and may be identical as enumeration names in other enumerated types; but shall not clash with any other global or local names.
i.e. allowed:
type enumerated Enum1 { e1, e2, e3 }
type enumerated Enum2 { e1, e2, e3 }
type record R {
Enum1 e1,
Enum2 e2
}

and these are not allowed:
type enumerated Enum3 { e11, e21, e31 }
const integer e11 := 0;
type integer e21;
type component CT {
var integer e31;
}
function F() {
var Enum2 e21
}

3) The rest:
I suppose it should be rather clear, the scoping rules apply. Global names shall be unique and local names shall be different from global names, local names in a higher scope (i.e. local var name of a function with a runs on clause shall differ from the names in the comp. type definition) and other names in the same scope. Pls. note, there is no specific rules/exceptions e.g. for port instance names; ports in different component types are always in different scope units as component types are always global definitions. So, the sentence "The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names." is just drawing the attention to something that is the outcome of the scoping rules anyway.
i.e. these are allowed:
type component CT {
const integer ci := 0;
port PT P1;
port PT P2
}
type component CTx {
port PT P1
}

function F1() {
const integer ci := 0;
}

function F2() {
const integer ci := 0;
}

but these are not:

---

type component CT1 {
const integer ci := 0;
}

function F() runs on CT1 {
const integer ci := 0;
}

---

type component CT2 {
port PT P
port PT P;
}

---

type integer I;
function F() {
var integer I
}

---

BR, Gyorgy

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 11:03
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Jacob,

let me just restrict for the moment to the example with the
type reference. Please find my comment below.

Same here ;-)





<--- snip, TD --->

The possibility to refer to the type of a record
field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}

I think V.d must be integer, because you cannot refer to
other fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could never be
disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is
integer.


Note that U in the field definition 'record {boolean T} U' is
not the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.

I have noted. U is both the name of a type and the name of a record
field. Since it is not possible to reference the record field without using the type prefix (V.U in your example), the reference 'U' in 'U.T d' must mean the type U, not the field U.


Why should it not be possible to refer to types of fields of
the same record?


Of course it is possible, but not without the explicit type prefix,
as field names can only be referenced relative to something.


type record X {
record of boolean b;
X.b c
}

should be ok, isn't it?

Yes, here you correctly reference the field b by using the type
prefix X.

BR, Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

<--- snip, TD --->



--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email
This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this message.

Hi Thomas and others,

The text precisely is: "

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. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."

So, it does not say that can be re-used in other enumarated types but says that can be re-used in other structured types.

Jacob's comment is correct. When discussing enumeration names many years ago, the majority opinion was to exclude potential name clashes between enumerations and names of other *definitions*, let it be local or global.

BR, Gyorgy



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 13:53
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Gyorgy,

In my opinion example 2 is not correct. The enumeration values are used also as field names within a record type, but clause 5.2.2 states "in the case of enumeration values the identifiers shall only be reused for enumeration values within other enumerated types" How does this fit together? What am I getting wrong?



I think what is MEANT here is that they shall not be used as 'scoped names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations.

Maybe this should be clarified.

BR, Jacob


Best regards

Thomas



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 26. September 2008 12:55
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hi,

This discussion starts to become a hard-to-follow to me, so I
will try to sum up what is allowed acc. to the standard and what is not.

1) Field names of record and set types and names of
alternatives in union types:
shall be unique among the other field/alternative names of
the given type only; i.e. may be the same as field/alternative/enumeration names in any other structured types and may be the same as the name of any global or local definition.
i.e., allowed:
type integer A;
type integer B;
type integer C;
type record D {
A A,
B B,
C C,
D D optional, //optional is a must here because
of the recursive reference
C E
}

type record E {
C C,
D.E c
// ^ pls. note, any dot reference shall start with the module
or global definition name
}
type component CT {
const integer c := 0
}

function F() {
const integer c := 0;
}

and this is not allowed:

type record E {
integer C,
octetstring C
}

2) Enumeration names in enumerated types:
Shall be unique within the type and may be identical as
enumeration names in other enumerated types; but shall not clash with any other global or local names.
i.e. allowed:
type enumerated Enum1 { e1, e2, e3 }

type enumerated Enum2 { e1, e2, e3 }
type record R {
Enum1 e1,
Enum2 e2
}


and these are not allowed:
type enumerated Enum3 { e11, e21, e31 }
const integer e11 := 0;
type integer e21;
type component CT {
var integer e31;
}
function F() {

var Enum2 e21
}

3) The rest:
I suppose it should be rather clear, the scoping rules apply.
Global names shall be unique and local names shall be different from global names, local names in a higher scope (i.e. local var name of a function with a runs on clause shall differ from the names in the comp. type definition) and other names in the same scope. Pls. note, there is no specific rules/exceptions e.g. for port instance names; ports in different component types are always in different scope units as component types are always global definitions. So, the sentence "The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names." is just drawing the attention to something that is the outcome of the scoping rules anyway.
i.e. these are allowed:

type component CT {
const integer ci := 0;
port PT P1;
port PT P2
}
type component CTx {
port PT P1
}

function F1() {
const integer ci := 0;
}


function F2() {
const integer ci := 0;
}

but these are not:

---

type component CT1 {
const integer ci := 0;
}

function F() runs on CT1 {
const integer ci := 0;
}

---

type component CT2 {
port PT P
port PT P;
}

---

type integer I;
function F() {
var integer I
}

---

BR, Gyorgy

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 11:03
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Jacob,

let me just restrict for the moment to the example
with the type reference. Please find my comment below.

Same here ;-)





<--- snip, TD --->

The possibility to refer to the type of a record
field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}

I think V.d must be integer, because you cannot
refer to other fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could
never be disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is
integer.


Note that U in the field definition 'record
{boolean T} U' is not the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.

I have noted. U is both the name of a type and the name
of a record field. Since it is not possible to reference the record field without using the type prefix (V.U in your example), the reference 'U' in 'U.T d' must mean the type U, not the field U.


Why should it not be possible to refer to types of
fields of the same record?


Of course it is possible, but not without the explicit
type prefix, as field names can only be referenced relative to something.


type record X {
record of boolean b;
X.b c
}

should be ok, isn't it?

Yes, here you correctly reference the field b by using
the type prefix X.

BR, Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

<--- snip, TD --->



--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles,
Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged
material for the
sole use of the intended recipient. Any review, use,
distribution or
disclosure by others is strictly prohibited. If you are
not the intended
recipient (or authorized to receive for the recipient),
please contact
the sender by reply e-mail and delete all copies of this
message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

--- On Fri, 26/9/08, György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:

From: György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Subject: Re: Uniqueness of identifiers
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Date: Friday, 26 September, 2008, 5:54 PM



Hi Thomas and others,
 
The text precisely is: "
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. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."
So, it does not say that can be re-used in other enumarated types but says that can be re-used in other structured types.
 
Jacob's comment is correct. When discussing enumeration names many years ago, the majority opinion was to exclude potential name clashes between enumerations and names of other *definitions*, let it be local or global.
 
BR, Gyorgy





From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 13:53
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Gyorgy,
 
In my opinion example 2 is not correct. The enumeration values are used also as field names within a record type, but clause 5.2.2 states "in the case of enumeration values the identifiers shall only be reused for enumeration values within other enumerated types" How does this fit together? What am I getting wrong?

I think what is MEANT here is that they shall not be used as 'scoped names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations.

Maybe this should be clarified.

BR, Jacob


Best regards
 
Thomas
 




From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 26. September 2008 12:55
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hi,
 
This discussion starts to become a hard-to-follow to me, so I will try to sum up what is allowed acc. to the standard and what is not.
 
1)    Field names of record and set types and names of alternatives in union types:
    shall be unique among the other field/alternative names of the given type only; i.e. may be the same as field/alternative/enumeration names in any other structured types and may be the same as the name of any global or local definition.
i.e., allowed:
type integer A;
type integer B;
type integer C;
type record  D {
    A        A,
    B        B,
    C        C,
    D        D    optional, //optional is a must here because of the recursive reference
    C        E
}
type record  E {
    C       C,
    D.E    c
//  ^ pls. note, any dot reference shall start with the module or global definition name
}
type component CT {
    const integer c := 0
}
 
function F() {
    const integer c := 0;
}
 
and this is not allowed:

type record  E {
    integer         C,
    octetstring    C
}
 
2)    Enumeration names in enumerated types:
Shall be unique within the type and may be identical as enumeration names in other enumerated types; but shall not clash with any other global or local names.
i.e. allowed:
type enumerated Enum1 { e1, e2, e3 }

type enumerated Enum2 { e1, e2, e3 }
type record R {
    Enum1    e1,
    Enum2    e2
}
 

and these are not allowed:type enumerated Enum3 { e11, e21, e31 }

const integer e11 := 0;
type integer e21;
type component CT {
    var integer e31;
}
function F() {

    var Enum2 e21
}
 
3) The rest:
I suppose it should be rather clear, the scoping rules apply. Global names shall be unique and local names shall be different from global names, local names in a higher scope (i.e. local var name of a function with a runs on clause shall differ from the names in the comp. type definition)  and other names in the same scope. Pls. note, there is no specific rules/exceptions e.g. for port instance names; ports in different component types are always in different scope units as component types are always global definitions. So, the sentence "The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names." is just drawing the attention to something that is the outcome of the scoping rules anyway.
i.e. these are allowed:

type component CT {
    const integer ci := 0;
    port PT P1;
    port PT P2
}
type component CTx {
    port PT P1
}
 
function F1() {
    const integer ci := 0;
}
 

function F2() {
    const integer ci := 0;
}
 
but these are not:

---

type component CT1 {
    const integer ci := 0;
}
 
function F() runs on CT1 {
    const integer ci := 0;
}

---

type component CT2 {
    port PT P
    port PT P;
}

---

type integer I;
function F() {
    var integer I
}

---

BR, Gyorgy



From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 11:03
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers

Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Jacob,
 
let me just restrict for the moment to the example with the type reference. Please find my comment below.Same here ;-)





 <--- snip, TD ---> 

The possibility to refer to the type of a record field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
  record {boolean T} U,
  U.T d
}
I think V.d must be integer, because you cannot refer to other fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could never be disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is integer. 
 
Note that U in the field definition 'record {boolean T} U' is not the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.I have noted. U is both the name of a type and the name of a record field. Since it is not possible to reference the record field without using the type prefix (V.U in your example), the reference 'U' in 'U.T d' must mean the type U, not the field U.


Why should it not be possible to refer to types of fields of the same record?
Of course it is possible, but not without the explicit type prefix, as field names can only be referenced relative to something.


type record X {
  record of boolean b;
  X.b c
}

should be ok, isn't it?Yes, here you correctly reference the field b by using the type prefix X.

BR, Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

 <--- snip, TD ---> 

--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.



Unlimited freedom, unlimited storage. Get it now, on help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

Hello Gyorgy,

it seems to me that the clauses in 6.2.4 and 5.2.2 are contradictory. The 6.2.x clauses seem to be more precise. Should we have a CR to remove the description of the exceptional cases from 5.2.2 and instead point to the corresponding clauses of 6.2.x?

Best regards

Thomas



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 26. September 2008 14:25
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hi Thomas and others,

The text precisely is: "

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. Enumeration identifiers shall only be reused within other structured type definitions and shall not be used for identifiers of local or global visibility at the same or a lower level of the same branch of the scope hierarchy (see scope hierarchy in clause 5.2)."

So, it does not say that can be re-used in other enumarated types but says that can be re-used in other structured types.

Jacob's comment is correct. When discussing enumeration names many years ago, the majority opinion was to exclude potential name clashes between enumerations and names of other *definitions*, let it be local or global.

BR, Gyorgy



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 13:53
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Gyorgy,

In my opinion example 2 is not correct. The enumeration values
are used also as field names within a record type, but clause 5.2.2 states "in the case of enumeration values the identifiers shall only be reused for enumeration values within other enumerated types" How does this fit together? What am I getting wrong?



I think what is MEANT here is that they shall not be used as 'scoped
names' except for other enumeration values. Scoped names being those in the scope hierarchy, not those of field declarations.

Maybe this should be clarified.

BR, Jacob


Best regards

Thomas



________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active
members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext György Réthy
Sent: Friday, 26. September 2008 12:55
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hi,

This discussion starts to become a hard-to-follow to me,
so I will try to sum up what is allowed acc. to the standard and what is not.

1) Field names of record and set types and names of
alternatives in union types:
shall be unique among the other field/alternative
names of the given type only; i.e. may be the same as field/alternative/enumeration names in any other structured types and may be the same as the name of any global or local definition.
i.e., allowed:
type integer A;
type integer B;
type integer C;
type record D {
A A,
B B,
C C,
D D optional, //optional is a must here
because of the recursive reference
C E
}

type record E {
C C,
D.E c
// ^ pls. note, any dot reference shall start with the
module or global definition name
}
type component CT {
const integer c := 0
}

function F() {
const integer c := 0;
}

and this is not allowed:

type record E {
integer C,
octetstring C
}

2) Enumeration names in enumerated types:
Shall be unique within the type and may be identical as
enumeration names in other enumerated types; but shall not clash with any other global or local names.
i.e. allowed:
type enumerated Enum1 { e1, e2, e3 }

type enumerated Enum2 { e1, e2, e3 }
type record R {
Enum1 e1,
Enum2 e2
}


and these are not allowed:
type enumerated Enum3 { e11, e21, e31 }
const integer e11 := 0;
type integer e21;
type component CT {
var integer e31;
}
function F() {

var Enum2 e21
}

3) The rest:
I suppose it should be rather clear, the scoping rules
apply. Global names shall be unique and local names shall be different from global names, local names in a higher scope (i.e. local var name of a function with a runs on clause shall differ from the names in the comp. type definition) and other names in the same scope. Pls. note, there is no specific rules/exceptions e.g. for port instance names; ports in different component types are always in different scope units as component types are always global definitions. So, the sentence "The port names in a component type definition are local to that component type, i.e. another component type may have ports with the same names." is just drawing the attention to something that is the outcome of the scoping rules anyway.
i.e. these are allowed:

type component CT {
const integer ci := 0;
port PT P1;
port PT P2
}
type component CTx {
port PT P1
}

function F1() {
const integer ci := 0;
}


function F2() {
const integer ci := 0;
}

but these are not:

---

type component CT1 {
const integer ci := 0;
}

function F() runs on CT1 {
const integer ci := 0;
}

---

type component CT2 {
port PT P
port PT P;
}

---

type integer I;
function F() {
var integer I
}

---

BR, Gyorgy

________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 -
active members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Jacob Wieland
Sent: 2008. szeptember 26. 11:03
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Uniqueness of identifiers


Hello Thomas,

Deiss, Thomas (NSN - DE/Duesseldorf) wrote:

Hello Jacob,

let me just restrict for the moment to the example
with the type reference. Please find my comment below.

Same here ;-)





<--- snip, TD --->

The possibility to refer to the type of a record
field creates an interesting puzzle. What's the type of the field V.d: boolean or integer?
type record U { integer T };
type record V {
record {boolean T} U,
U.T d
}

I think V.d must be integer, because you cannot
refer to other fields in the type of the declaration of a field (because of the rule that these
names need not be disjoint and therefore could
never be disambiguated via a prefix), but only to globally declared types.
Thus, U.T must mean field T of type U, which is
integer.


Note that U in the field definition 'record
{boolean T} U' is not the name of a type, which does not have to be unique as you correctly observe. U is the name of a field, and this has to be unique within V.

I have noted. U is both the name of a type and the
name of a record field. Since it is not possible to reference the record field without using the type prefix (V.U in your example), the reference 'U' in 'U.T d' must mean the type U, not the field U.


Why should it not be possible to refer to types of
fields of the same record?


Of course it is possible, but not without the
explicit type prefix, as field names can only be referenced relative to something.


type record X {
record of boolean b;
X.b c
}

should be ok, isn't it?

Yes, here you correctly reference the field b by
using the type prefix X.

BR, Jacob


--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

<--- snip, TD --->



--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet
www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test
Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles,
Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht
Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and
privileged material for the
sole use of the intended recipient. Any review,
use, distribution or
disclosure by others is strictly prohibited. If
you are not the intended
recipient (or authorized to receive for the
recipient), please contact
the sender by reply e-mail and delete all copies
of this message.




--

---

Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email
This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

UPCOMING EVENTS!

September 24-26, Conquest, Booth #004
Potsdam, Germany
www.isqi.org/konferenzen/conquest/2008/

September 27, ASQF Golf Cup
Potsdam, Germany
www.asqf.de/veranstaltungen/4-asqf-golf-cup/

October 15, Free Webinar "TTCN-3 for Test Automation"
www.testingtech.com/services/ttcn3_webinar.php

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please
contact
the sender by reply e-mail and delete all copies of this message.