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

ID | Project | Category | View Status | Date Submitted | Last Update
0007445 | Part 01: TTCN-3 Core Language | New Feature | public | 17-06-2016 13:07 | 08-09-2017 10:52

Reporter | Jacob Wieland - Spirent |
Assigned To | Tomas Urban |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.10.1 (published 2018-05) | Fixed in Version | v4.10.1 (published 2018-05) |
Clause Reference(s) | 27
Source (company - Author) | Spirent - Jacob Wieland

Summary | 0007445: usage of encode/variant attributes should be enhanced

Description

In a user scenario, the same data shall sometimes be encoded with different encodings which have different variant attributes to configure the codec.
This is not easily accomplished by TTCN-3 at the moment as any type/member can only have one encode/variant attribute (or the semantics of multiplicity of such attributes is unspecified) and the variant attribute is tied to the encoding attribute. Thus, you would need two copies of the same type system with different attributes attached and, following that, copies of all the templates for these types, as well and selection expressions at all usage points which makes the whole thing very hard to manage.
What would be necessary to achieve the single-type/template approach would be to allow, at least on the type definition level, to add multiple encode/variant attributes and to somehow tag variant attributes with the encoding rule they are tied to.
Care must also be taken on the TCI level with the functions getType() getTypeEncoding() getTypeEncodingVariant() getValueEncoding() and getValueEncodingVariant(). Ideally, a codec should be unaware of the encoding/variant multiplicity and still work with the assumption that the value-encoding of the template to be encoded establishes the relevant encoding context.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007448 | closed | Gyorgy Rethy | Allowing multiple encodings for TTCN-3 types
related to | 0007707 | closed | Gyorgy Rethy | Port and timer variables and structured types containing ports and timers

Attached Files |

Issue History
Date Modified | Username | Field | Change
17-06-2016 13:07 | Jacob Wieland - Spirent | New Issue |
11-07-2016 10:27 | Jacob Wieland - Spirent | Relationship added | related to 0007448
18-07-2016 10:02 | Jens Grabowski | Assigned To | => Tomas Urban
18-07-2016 10:02 | Jens Grabowski | Status | new => assigned
16-08-2016 16:26 | Tomas Urban | Note Added: 0014116 |
16-08-2016 16:26 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
16-08-2016 16:26 | Tomas Urban | Status | assigned => confirmed
17-08-2016 11:09 | Jacob Wieland - Spirent | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
17-08-2016 11:10 | Jacob Wieland - Spirent | Target Version | => v4.9.1 (published 2017-05)
18-08-2016 10:59 | Jens Grabowski | Assigned To | Jens Grabowski => KristÃ³f Szabados
18-08-2016 10:59 | Jens Grabowski | Status | confirmed => assigned
18-08-2016 10:59 | Jens Grabowski | Status | assigned => confirmed
19-08-2016 13:34 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
19-08-2016 13:34 | KristÃ³f Szabados | Status | confirmed => assigned
19-08-2016 15:01 | Jacob Wieland - Spirent | Note Added: 0014187 |
19-08-2016 15:01 | Jacob Wieland - Spirent | Status | assigned => confirmed
14-11-2016 13:14 | Jacob Wieland - Spirent | Note Added: 0014228 |
14-11-2016 13:16 | Jacob Wieland - Spirent | Note Edited: 0014228 | bug_revision_view_page.php?bugnote_id=14228#r330
14-11-2016 15:59 | Jens Grabowski | Note Added: 0014231 |
15-11-2016 09:41 | Jacob Wieland - Spirent | Note Added: 0014235 |
15-11-2016 09:41 | Jacob Wieland - Spirent | Severity | major => minor
15-11-2016 09:41 | Jacob Wieland - Spirent | Status | confirmed => new
15-11-2016 09:41 | Jacob Wieland - Spirent | Target Version | v4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
17-11-2016 14:04 | Jens Grabowski | Status | new => assigned
08-09-2017 10:26 | Tomas Urban | Assigned To | Jacob Wieland - Spirent => Tomas Urban
08-09-2017 10:43 | Tomas Urban | Relationship added | related to 0007707
08-09-2017 10:52 | Tomas Urban | Note Added: 0014826 |
08-09-2017 10:52 | Tomas Urban | Status | assigned => closed
08-09-2017 10:52 | Tomas Urban | Resolution | open => fixed
08-09-2017 10:52 | Tomas Urban | Fixed in Version | => v4.10.1 (published 2018-05)

Notes

(0014116)
Tomas Urban
16-08-2016 16:26

Resolved as a part of resolution of the related CR 0007448.

(0014187)
Jacob Wieland - Spirent
19-08-2016 15:01

please review

(0014228)
Jacob Wieland - Spirent
14-11-2016 13:14 (edited on: 14-11-2016 13:16)

Using the following pattern, the existing syntactical elements of TTCN-3 could already be used to write such code.
Let's assume our PDU type is PDU.
We would declare
type port PDUPort message { inout PDU }
type PDUPort JSONPDUPort with { encode "JSON" }
type PDUPort XMLPDUPort with { encode "XML" }
component PDUComponent {
port JSONPDUPOrt jsonPort;
port XMLPDUPort xmlPort;
var PDUPort pduPort;
}
function configure() runs on PDUComponent {
if (useJSON) { pduPort := jsonPort; } else { pduPort := xmlPort; }
}
Then, in the rest of the code, we would simply use the port variable and never the concrete ones directly.

(0014231)
Jens Grabowski
14-11-2016 15:59

STF agreement: Use resolution as proposed in CR 7448. This proposal may be discussed in the scope of the 2017 TTCN-3 STF.

(0014235)
Jacob Wieland - Spirent
15-11-2016 09:41

I shift this to the future so we don't forget about it.

(0014826)
Tomas Urban
08-09-2017 10:52

The original issue was handled in the related CR 0007448 and the proposed introduction of port variables has its own dedicated CR 0007707. As there are no more issues left, the CR has been closed by STF 533.