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

ID | Project | Category | View Status | Date Submitted | Last Update
0007141 | Part 01: TTCN-3 Core Language | Clarification | public | 14-08-2015 12:50 | 11-12-2015 15:03

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | low | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.7.1 (published 2015-06) |
Target Version | v4.8.1 (published 2016-07) | Fixed in Version | v4.8.1 (published 2016-07) |
Clause Reference(s) | 6.3.4
Source (company - Author) | STF 487

Summary | 0007141: Strong typing rules

Description

The current rules on strong typing specified in 6.3.4 say: The types of values or templates directly used as parameters to these operations [send, receive, trigger, call, getcall, reply, getreply and raise and connection operations connect, map, disconnect and unmap] shall also be explicitly defined in the associated port type definition.
This rule is fine for the send and receive operation, but not applicable to the remaining operations. In case of procedure-based communication operations, there are several problems:
1. Associated port type definition doesn't contain types in this case, but signatures. TTCN-3 doesn't allow to create signature aliases, thus signature templates are implicitly strongly typed.
2. In case of the reply and getreply operation, it is not obvious whether the value part shall be strongly typed or not. The existing rule is not helpful (even if we consider signature to be a type) as the return value type is defined in the signature and not in the associated port definition. In theory, strong typing is not necessary as the return value type is implicitly available through the signature template and the provided value/template can be safely converted to this type.
3. In case of the raise and catch operation, the exception value type is again not explicitly defined in the associated port type definition. Correct statement would be that the signature shall be explicitly defined in the associated port type definition and the exception value/template type shall be explicitly defined in the signature exception list. Strong typing is required in this case as the exception list might contain several distinct compatible types.
For the map, unmap and component operation, the rule doesn't make sense either. Strong typing is related to the system, runs on and mtc clauses in this case - it is used to verify that ports used as parameters of these calls are present in the component.
It should be also explained whether strong typing is applied to the to/from clause and if so how exaclty it works.
Proposal: Rewording required to address all above mentioned issues.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7141_resolution_v1.docx (77,459) 03-11-2015 09:05 http://oldforge.etsi.org/mantis/file_download.php?file_id=3343&type=bug CR7141_resolution_v2.docx (93,366) 03-11-2015 10:20 http://oldforge.etsi.org/mantis/file_download.php?file_id=3344&type=bug CR7149_resolution_v3.docx (68,376) 04-11-2015 10:09 http://oldforge.etsi.org/mantis/file_download.php?file_id=3356&type=bug

Issue History
Date Modified | Username | Field | Change
14-08-2015 12:50 | Tomas Urban | New Issue |
21-09-2015 10:27 | Gyorgy Rethy | Target Version | => v4.8.1 (published 2016-07)
21-09-2015 15:53 | Gyorgy Rethy | Note Added: 0013220 |
21-09-2015 15:54 | Gyorgy Rethy | Priority | normal => low
02-11-2015 15:40 | Axel Rennoch | Assigned To | => Axel Rennoch
02-11-2015 15:40 | Axel Rennoch | Status | new => assigned
03-11-2015 09:05 | Axel Rennoch | File Added: CR7141_resolution_v1.docx |
03-11-2015 09:07 | Axel Rennoch | Note Added: 0013450 |
03-11-2015 09:09 | Axel Rennoch | Note Added: 0013451 |
03-11-2015 09:09 | Axel Rennoch | Assigned To | Axel Rennoch => Jacob Wieland - Spirent
03-11-2015 09:09 | Axel Rennoch | Status | assigned => feedback
03-11-2015 10:19 | Jacob Wieland - Spirent | Note Added: 0013455 |
03-11-2015 10:20 | Jacob Wieland - Spirent | File Added: CR7141_resolution_v2.docx |
03-11-2015 10:20 | Jacob Wieland - Spirent | Note Added: 0013456 |
03-11-2015 10:20 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
03-11-2015 10:20 | Jacob Wieland - Spirent | Status | feedback => confirmed
04-11-2015 10:09 | Jens Grabowski | File Added: CR7149_resolution_v3.docx |
04-11-2015 10:09 | Jens Grabowski | Note Added: 0013483 |
04-11-2015 10:09 | Jens Grabowski | Assigned To | Jens Grabowski =>
04-11-2015 10:10 | Jens Grabowski | Assigned To | => Gyorgy Rethy
04-11-2015 10:10 | Jens Grabowski | Status | confirmed => resolved
04-11-2015 14:03 | Gyorgy Rethy | Fixed in Version | => v4.8.1 (published 2016-07)
11-12-2015 15:03 | Gyorgy Rethy | Note Added: 0013597 |
11-12-2015 15:03 | Gyorgy Rethy | Status | resolved => closed
11-12-2015 15:03 | Gyorgy Rethy | Resolution | open => fixed

Notes

(0013220)
Gyorgy Rethy
21-09-2015 15:53

STF discussion: CR to be handled with low prioriy

(0013450)
Axel Rennoch
03-11-2015 09:07

uploaded file considers the CR and removes a contradiction with section 22.2.2 that does not require strong typing for the assignment of messages in receive/trigger operations.

(0013451)
Axel Rennoch
03-11-2015 09:09

Please review the current resolution_v1 and consider additional rewording for further improvements.

(0013455)
Jacob Wieland - Spirent
03-11-2015 10:19

removed additional restriction to connection operations (no such restriction is necessary, would be backward incompatible)
Also reworded the description referencing the different cases:
- values of send, receive, trigger
- parameter signatures of call, getcall, reply, getreply
- signature type of catch and raise
- exceptions of catch and raise
For return value part of reply/getreply and for parameters contained in the signature-template for call/getcall/reply/getreply, no strong typing is necessary.

(0013456)
Jacob Wieland - Spirent
03-11-2015 10:20

please review and resolve

(0013483)
Jens Grabowski
04-11-2015 10:09

Two typos removed. Set to resolved and assigned to György.

(0013597)
Gyorgy Rethy
11-12-2015 15:03

Added to draft V4.7.4