ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
0005588Part 01: TTCN-3 Core LanguageTechnicalpublic02-07-2010 10:3014-12-2010 23:52
Gyorgy Rethy 
Ina Schieferdecker 
normalminorhave not tried
closedfixed 
 
v4.3.1 (published 2011-06)v4.3.1 (published 2011-06) 
at least 6.2.9, 6.2.12, 22
     
0005588: Follow-up of CR2105 - Deprecating using addressing without explicit binding the addressing type to the port type
CR2105 allowed binding a type to be used for addressing to port types. The next step would be to remove the drawbacks of using the address type without explicit declaration of the need to support addressing in the port type definition, i.e. deprecate using to/from in mapped port when no address type is declared in the related port type definition. Pls. note, deprecate does not mean removing from the standard or forbid using it in existing test suites. It is a signal that users should use the new feature in new code and - over a longer period of time - refrain from it also in the old code basis.
No tags attached.
related to 0002105closed Ina Schieferdecker address should also be bind to port type 
doc CR-2105 + CR-5588.doc (97,280) 01-09-2010 10:55
http://oldforge.etsi.org/mantis/file_download.php?file_id=2421&type=bug
doc CR-2105 + CR-5588-Jacob.doc (57,856) 01-09-2010 11:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2422&type=bug
? core.bnf (55,689) 14-12-2010 23:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=2471&type=bug
Issue History
02-07-2010 10:30Gyorgy RethyNew Issue
02-07-2010 10:30Gyorgy RethyClause Reference(s) => at least 6.2.9, 6.2.12, 22
02-07-2010 10:30Gyorgy RethySource (company - Author) =>
02-07-2010 10:48Gyorgy RethyProjectTTCN-3 Change Requests => Part 01: TTCN-3 Core Language
02-07-2010 10:49Gyorgy RethyTarget Version => Edition 4.3.1 (not yet published)
30-08-2010 12:13Gyorgy RethyNote Added: 0009653
30-08-2010 12:14Gyorgy RethyStatusnew => assigned
30-08-2010 12:14Gyorgy RethyAssigned To => Benjamin Zeiss
01-09-2010 10:55Benjamin ZeissNote Added: 0009669
01-09-2010 10:55Benjamin ZeissFile Added: CR-2105 + CR-5588.doc
01-09-2010 10:56Benjamin ZeissAssigned ToBenjamin Zeiss => Jacob Wieland - Spirent
01-09-2010 11:48Jacob Wieland - SpirentNote Added: 0009673
01-09-2010 11:48Jacob Wieland - SpirentFile Added: CR-2105 + CR-5588-Jacob.doc
01-09-2010 11:49Jacob Wieland - SpirentNote Added: 0009674
01-09-2010 17:09Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Jens Grabowski
01-09-2010 17:13Benjamin ZeissAssigned ToJens Grabowski => Ina Schieferdecker
01-09-2010 17:13Benjamin ZeissStatusassigned => resolved
01-09-2010 17:13Benjamin ZeissResolutionopen => fixed
01-09-2010 17:13Benjamin ZeissNote Added: 0009686
14-12-2010 15:39Ina SchieferdeckerRelationship addedrelated to 0002105
14-12-2010 15:41Ina SchieferdeckerNote Added: 0009971
14-12-2010 23:51Ina SchieferdeckerNote Added: 0009972
14-12-2010 23:52Ina SchieferdeckerFile Added: core.bnf
14-12-2010 23:52Ina SchieferdeckerStatusresolved => closed
14-12-2010 23:52Ina SchieferdeckerFixed in Version => Edition 4.3.1 (not yet published)

Notes
(0009653)
Gyorgy Rethy   
30-08-2010 12:13   
global address type has effect on port type defintions in the same module only without local address type reference.
(0009669)
Benjamin Zeiss   
01-09-2010 10:55   
Attached a rephrasing proposal to the CR 2105 proposal to reflect the recommended use.
(0009673)
Jacob Wieland - Spirent   
01-09-2010 11:48   
The following sentence does not make sense in the context of the new port-bound address feature:

"Explicit SUT addresses shall only be generated inside a TTCN‑3 module if the type is defined inside the module (globally or within port type definitions). If the type is not defined inside the module, explicit SUT addresses shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls."

It should (at least) be changed to:

"Explicit SUT addresses for a globally defined address type shall only be generated inside a TTCN‑3 module if the type is defined inside the module itself. If the type is not defined inside the module, explicit SUT addresses for a global address type shall only be passed in as parameters or be received in message fields or as parameters of remote procedure calls."

In my opinion, the whole sentence could be removed as it is an unnecessary restriction. Why should not module B which imports module A, then use A.address like any other type if it uses a port type defined in module A which has no address-type bound?

==============================================================================
The example which receives addresses should instead be changed to use the sender/from clause(s) because there you need the agreement between the address variables and the address type.
(0009674)
Jacob Wieland - Spirent   
01-09-2010 11:49   
added my changes in CR-2105 + CR-5588-Jacob.doc
(0009686)
Benjamin Zeiss   
01-09-2010 17:13   
Looks good to me. Assigned to Ina.
(0009971)
Ina Schieferdecker   
14-12-2010 15:41   
The agreed syntax from CR2105 is implemented in part 1:

type port PortTypeIdentifier message "{"
        [ address Type “;” ]
        [ map param "(" { FormalValuePar [","] }+ ")" ]
        [ unmap param "(" { FormalValuePar [","] }+ ")" ]
        { ( in | out | inout ) { MessageType [ "," ] }+ ";" }
"}"

etc.
(0009972)
Ina Schieferdecker   
14-12-2010 23:51   
see uploaded BNF for defining address types in ports