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

ID | Project | Category | View Status | Date Submitted | Last Update
0002105 | Part 01: TTCN-3 Core Language | New Feature | public | 04-10-2007 18:10 | 01-12-2010 14:37

Reporter | tepelmann |
Assigned To | Ina Schieferdecker |
Priority | low | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.1 (published 2011-06) | Fixed in Version | v4.3.1 (published 2011-06) |
Clause Reference(s) | 9.1
Source (company - Author) | Testing Technologies - Dirk Tepelmann

Summary | 0002105: address should also be bind to port type

Description

Currently the address is bound module-wise, however in my opinion it should also be possible to bind the address type to a port type declaration as the port type defines the communication.
This enables the usage of different address types port-type-wise.
type port PortTypeIdentifier message "{"
{ ( in | out | inout ) ( all | { MessageType [ "," ] }+ ) ";" }
{ address { MessageType } ";" }
"}"
To reference the specific address type, the type should be retrievable via dotted notation based on the port type(similiar to the access of anonymous inline type definitions in structured types).
var <port type>.address <varIdentifier> ":=" Expression

Steps To Reproduce |
Additional Information | E.g.: type port P message { inout all; address integer; }; type port Q message { inout all; address charstring; }; function f() runs on C { var P.address addr0 := 0; p.send(AAA) to 0; p.send(AAA) to addr0; q.send(BBB) to "127.0.0.1"; }
Tags | No tags attached.

Relationships

related to | 0005417 | closed | Ina Schieferdecker | Support of parametrized map/unmap operation for full dynamic mapping
related to | 0005588 | closed | Ina Schieferdecker | Follow-up of CR2105 - Deprecating using addressing without explicit binding the addressing type to the port type
related to | 0005923 | closed | Ina Schieferdecker | BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match

Attached Files

CR-2105-address-bound-to-port-type-Resolution-V1-081222.doc (189,440) 22-12-2008 12:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=1924&type=bug
CR2105-Resolution-Jens-100630.zip (48,382) 30-06-2010 16:04
http://oldforge.etsi.org/mantis/file_download.php?file_id=2389&type=bug
CR2105-Resolution-Jens-100702.zip (49,161) 02-07-2010 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=2401&type=bug
CR2105-Resolution-101201.doc (300,032) 01-12-2010 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=2451&type=bug
CR2105-Resolution-101201a.doc (227,840) 01-12-2010 14:36
http://oldforge.etsi.org/mantis/file_download.php?file_id=2458&type=bug

Issue History
Date Modified | Username | Field | Change
04-10-2007 18:10 | tepelmann | New Issue |
04-10-2007 18:10 | tepelmann | Status | new => assigned
04-10-2007 18:10 | tepelmann | Assigned To | => Gyorgy Rethy
04-10-2007 18:10 | tepelmann | Clause Reference(s) | => 9.1
04-10-2007 18:10 | tepelmann | Source (company - Author) | => Testing Technologies - Dirk Tepelmann
13-10-2007 18:53 | Ina Schieferdecker | Assigned To | Gyorgy Rethy => Jens Grabowski
17-10-2007 11:18 | Ina Schieferdecker | Note Added: 0003655 |
17-10-2007 11:18 | Ina Schieferdecker | Category | Technical => New Feature
18-10-2007 13:46 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
18-10-2007 13:58 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published)
18-07-2008 09:51 | Jens Grabowski | Note Added: 0006327 |
22-12-2008 12:34 | Jens Grabowski | Note Added: 0007758 |
22-12-2008 12:36 | Jens Grabowski | File Added: CR-2105-address-bound-to-port-type-Resolution-V1-081222.doc |
22-12-2008 12:36 | Jens Grabowski | Assigned To | Jens Grabowski =>
22-12-2008 12:36 | Jens Grabowski | Assigned To | => Ina Schieferdecker
22-12-2008 12:37 | Ina Schieferdecker | Note Added: 0007759 |
22-12-2008 12:37 | Ina Schieferdecker | Target Version | Edition 4.1.1 (not yet published) => Edition 4.2.1 (not yet published)
22-12-2008 12:48 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jens Grabowski
16-02-2010 14:23 | Jens Grabowski | Status | assigned => closed
16-02-2010 14:23 | Jens Grabowski | Note Added: 0009216 |
16-02-2010 14:23 | Jens Grabowski | Resolution | open => won't fix
16-02-2010 15:22 | tepelmann | Status | closed => feedback
16-02-2010 15:22 | tepelmann | Resolution | won't fix => reopened
16-02-2010 15:22 | tepelmann | Note Added: 0009225 |
18-03-2010 07:32 | Ina Schieferdecker | Target Version | Edition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
23-03-2010 13:06 | Gyorgy Rethy | Priority | normal => low
24-03-2010 08:54 | Jacob Wieland - Spirent | Note Added: 0009273 |
24-03-2010 08:56 | Jacob Wieland - Spirent | Relationship added | related to 0005417
25-03-2010 09:08 | Gyorgy Rethy | Note Added: 0009294 |
25-03-2010 09:09 | Gyorgy Rethy | Note Edited: 0009294 |
26-03-2010 09:39 | Gyorgy Rethy | Status | feedback => assigned
26-03-2010 09:41 | Gyorgy Rethy | Note Added: 0009321 |
26-03-2010 14:37 | Gyorgy Rethy | Note Edited: 0009294 |
30-06-2010 16:04 | Jens Grabowski | File Added: CR2105-Resolution-Jens-100630.zip |
30-06-2010 16:05 | Jens Grabowski | Note Added: 0009435 |
30-06-2010 16:05 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
01-07-2010 10:37 | Gyorgy Rethy | Note Added: 0009443 |
01-07-2010 10:38 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
02-07-2010 10:02 | Jens Grabowski | Note Added: 0009462 |
02-07-2010 10:02 | Jens Grabowski | Assigned To | Jens Grabowski => Ina Schieferdecker
02-07-2010 10:02 | Jens Grabowski | Status | assigned => resolved
02-07-2010 10:02 | Jens Grabowski | Resolution | reopened => fixed
02-07-2010 10:21 | Gyorgy Rethy | Note Added: 0009463 |
02-07-2010 10:21 | Gyorgy Rethy | Status | resolved => assigned
02-07-2010 10:21 | Gyorgy Rethy | Note Edited: 0009463 |
02-07-2010 11:10 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Jens Grabowski
02-07-2010 11:32 | Jens Grabowski | File Added: CR2105-Resolution-Jens-100702.zip |
02-07-2010 11:33 | Jens Grabowski | Note Added: 0009469 |
02-07-2010 11:33 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
01-12-2010 10:07 | Gyorgy Rethy | Note Added: 0009877 |
01-12-2010 10:15 | Gyorgy Rethy | Note Edited: 0009877 |
01-12-2010 10:16 | Gyorgy Rethy | File Added: CR2105-Resolution-101201.doc |
01-12-2010 10:16 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
01-12-2010 13:56 | Ina Schieferdecker | Note Added: 0009896 |
01-12-2010 13:57 | Ina Schieferdecker | File Added: CR2105-Resolution-101201a.doc |
01-12-2010 13:57 | Ina Schieferdecker | Status | assigned => resolved
01-12-2010 13:57 | Ina Schieferdecker | Fixed in Version | => Edition 4.3.1 (not yet published)
01-12-2010 14:36 | Ina Schieferdecker | File Deleted: CR2105-Resolution-101201a.doc |
01-12-2010 14:36 | Ina Schieferdecker | File Added: CR2105-Resolution-101201a.doc |
01-12-2010 14:37 | Ina Schieferdecker | Status | resolved => closed
14-12-2010 15:39 | Ina Schieferdecker | Relationship added | related to 0005588
29-09-2011 09:47 | Ina Schieferdecker | Relationship added | related to 0005923

Notes

(0003655)
Ina Schieferdecker
17-10-2007 11:18

This CR is to be considered in the wider scope of test configuration and therefore considered in 2008 only.

(0006327)
Jens Grabowski
18-07-2008 09:51

CR is in principle OK. Proposed implementation in the standard needs to be refined.

(0007758)
Jens Grabowski
22-12-2008 12:34

The following problems arose when trying to implement this CR.
(1) Clause 5.2.2 "Uniqueness of identifiers" will be violated because the keyword address (which is also the identifier of that type) may be bound to several types within one module. So far, TTCN-3 only allows dot notation to resolve ambiguities with identifiers only on module level (e.g., the module identifier is used to distinguish between local and imported definitions). Weakening this clause requires a larger discussion (why shall overloading only allowed for the address type?).
(2) Implementing this CR requires larger changes in the BNF. Special rules have to be defined to allow the binding of the address type to a port and the dot notation with port type identifiers has to be introdruced for referenced types.
The conclusion is that the CR looks simple and easy to implement, but needs a further discussion. Therefore, the CR should be moved to 2009.
A proposal for the text implementing the CR in the clauses 6.2.9 and 6.2.12 is uploaded.

(0007759)
Ina Schieferdecker
22-12-2008 12:37

This CR requires more discussion

(0009216)
Jens Grabowski
16-02-2010 14:23

Issue was reported 3 years ago! After report no one again showed interest in this CR. Therefore, it is closed.

(0009225)
tepelmann
16-02-2010 15:22

Testing Technologies still claim interest for this CR. If any clarification or support can be provided, don't hesitate to contact us.

(0009273)
Jacob Wieland - Spirent
24-03-2010 08:54

The problems mentioned earlier with this CR are (in part) not valid anymore, as now the BNF already allows referencing parts of types for structured types. To enlarge the semantics to work on port-types as well (with the special field reference address which should be the address type specified in the port type, and only applicable if such an address type was specified). There is no overloading involved as the declarations would be local to the port type definition.
However, this is not really necessary at all as one could always just reference the type of the address specification of the port directly.
So, instead of
var P.address x := 0;
one could write
var integer x := 0;
The static semantics would need to reflect that the referenced address expressions used in to and from clauses are compatible with the address type of the port (if one is declared in its type).
Thus, the only really necessary changes in the standard are the addition of the address declaration in the port type definition and the change in the description of the to/from clauses accordingly.

(0009294)
Gyorgy Rethy
25-03-2010 09:08 (edited on: 26-03-2010 14:37)

I agree that the addressing should be bound to the port type, as today no one can know that in case of which port implementations the address type should be supported and in which cases it is not needed (i.e. how to implement it in the adapter).
1. I don't like the syntax, namely using the type keyword inside a port type definition. It looks like as if a new type had been defined, while this is not the case. The type has to be defined normally, as a global type (or is a built-in type) and the port type shall just denote that it wants to use that type definition for addressing purposes. I propose instead:
type port MyPort
message {
inout Tinky-winky,
address MyRecordType
}
procedure {
inout Gipsy,
address integer
}
2. It should be made explicit that a port either using the global address type OR its own address binding, i.e. if a port type binds a global type for addressing, instances of that port type shall not use the global address type.

(0009321)
Gyorgy Rethy
26-03-2010 09:41

status feedback shall only be used when we are waiting for an external feedback.

(0009435)
Jens Grabowski
30-06-2010 16:05

Resolution version 1 uploaded, re-assigned to GyÃ¶rgy for proofreading.

(0009443)
Gyorgy Rethy
01-07-2010 10:37

The proposed text is quite OK but I propose to make explicit address type declaration in port types mandatory; i.e. deprecate the feature of using to/from clauses on mapped ports without explicit address type declaration. This would allow using the predefined type name address further on (otherwise we would have backward compatibility problem) but would remove the problems we have today:
- there is a strange implicit binding by declaring address and the port type within the same module that is not optimal for practical use (normally each port type is declared in a separate module to allow th user to select which ports he/she wants to use).
- but if several port types are declared in the same module it is unclear today that in context of which addressing can be used and in context of which it shall not be used. This information is not given in the TTCN-3 code, thus the code has to be supplemented with an informal information specifying this (adapter implementation issue).
The syntax, when using the address type:
type port message {
address address,
...
looks a little bit strange, but I think this is some thing we can and have to live with...

(0009462)
Jens Grabowski
02-07-2010 10:02

Deprecating the address type should be proposed in a new CR which should be discussed with MTS and possibly the tool vendors. Removing the address type from the text requires some work. For the moment, I assign the CR to Ina, set the resolution to fixed and set the status to resolved.

(0009463)
Gyorgy Rethy
02-07-2010 10:21

The new restrictions that
AddressRef shall not contain matching mechanisms
is not correct. We allowed using templates in to/from clauses to support multicasting and be able to provide a list of addressees in form of a value list. But value list is a matching mechanism, so at least value list matching shall be allowed in both to and from clauses. But in fact in most cases addresses are not simple types but structured types, mostly records. Why disallow e.g.
... from { connEP := ?, entity:= XYentity } ...?

(0009469)
Jens Grabowski
02-07-2010 11:33

New resolution text uploaded. Reassigned to GyÃ¶rgy for proofreading.

(0009877)
Gyorgy Rethy
01-12-2010 10:07 (edited on: 01-12-2010 10:15)

I have noticed that the syntactical structures in clauses 22.2.1-22.4 contain AddressRef only (no AddressRefList and all|any component), so added a note to clarify this. Plus editorials. Pls. cross-check. See CR2105-Resolution-101201.doc

(0009896)
Ina Schieferdecker
01-12-2010 13:56

basically ok, some smaller corrections and simplifications only