Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005588Part 01: TTCN-3 Core LanguageTechnicalpublic02-07-2010 10:3014-12-2010 23:52
ReporterGyorgy Rethy 
Assigned ToIna Schieferdecker 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.3.1 (published 2011-06)Fixed in Versionv4.3.1 (published 2011-06) 
Summary0005588: Follow-up of CR2105 - Deprecating using addressing without explicit binding the addressing type to the port type
DescriptionCR2105 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.
TagsNo tags attached.
Clause Reference(s)at least 6.2.9, 6.2.12, 22
Source (company - Author)     
Attached Filesdoc file icon CR-2105 + CR-5588.doc [^] (97,280 bytes) 01-09-2010 10:55
doc file icon CR-2105 + CR-5588-Jacob.doc [^] (57,856 bytes) 01-09-2010 11:48
? file icon core.bnf [^] (55,689 bytes) 14-12-2010 23:52

- Relationships
related to 0002105closedIna Schieferdecker address should also be bind to port type 

-  Notes
(0009653)
Gyorgy Rethy (reporter)
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 (reporter)
01-09-2010 10:55

 Attached a rephrasing proposal to the CR 2105 proposal to reflect the recommended use.
(0009673)
Jacob Wieland - Spirent (reporter)
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 (reporter)
01-09-2010 11:49

 added my changes in CR-2105 + CR-5588-Jacob.doc
(0009686)
Benjamin Zeiss (reporter)
01-09-2010 17:13

 Looks good to me. Assigned to Ina.
(0009971)
Ina Schieferdecker (reporter)
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 (reporter)
14-12-2010 23:51

 see uploaded BNF for defining address types in ports

- Issue History
Date Modified Username Field Change
02-07-2010 10:30 Gyorgy Rethy New Issue
02-07-2010 10:30 Gyorgy Rethy Clause Reference(s) => at least 6.2.9, 6.2.12, 22
02-07-2010 10:30 Gyorgy Rethy Source (company - Author) =>
02-07-2010 10:48 Gyorgy Rethy Project TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
02-07-2010 10:49 Gyorgy Rethy Target Version => Edition 4.3.1 (not yet published)
30-08-2010 12:13 Gyorgy Rethy Note Added: 0009653
30-08-2010 12:14 Gyorgy Rethy Status new => assigned
30-08-2010 12:14 Gyorgy Rethy Assigned To => Benjamin Zeiss
01-09-2010 10:55 Benjamin Zeiss Note Added: 0009669
01-09-2010 10:55 Benjamin Zeiss File Added: CR-2105 + CR-5588.doc
01-09-2010 10:56 Benjamin Zeiss Assigned To Benjamin Zeiss => Jacob Wieland - Spirent
01-09-2010 11:48 Jacob Wieland - Spirent Note Added: 0009673
01-09-2010 11:48 Jacob Wieland - Spirent File Added: CR-2105 + CR-5588-Jacob.doc
01-09-2010 11:49 Jacob Wieland - Spirent Note Added: 0009674
01-09-2010 17:09 Jacob Wieland - Spirent Assigned To Jacob Wieland - Spirent => Jens Grabowski
01-09-2010 17:13 Benjamin Zeiss Assigned To Jens Grabowski => Ina Schieferdecker
01-09-2010 17:13 Benjamin Zeiss Status assigned => resolved
01-09-2010 17:13 Benjamin Zeiss Resolution open => fixed
01-09-2010 17:13 Benjamin Zeiss Note Added: 0009686
14-12-2010 15:39 Ina Schieferdecker Relationship added related to 0002105
14-12-2010 15:41 Ina Schieferdecker Note Added: 0009971
14-12-2010 23:51 Ina Schieferdecker Note Added: 0009972
14-12-2010 23:52 Ina Schieferdecker File Added: core.bnf
14-12-2010 23:52 Ina Schieferdecker Status resolved => closed
14-12-2010 23:52 Ina Schieferdecker Fixed in Version => Edition 4.3.1 (not yet published)

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker