ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0007421 | Part 09: Using XML with TTCN-3 | New Feature | public | 01-03-2016 13:14 | 13-12-2016 17:05

Reporter | Thilo Lauer |
Assigned To | Gyorgy Rethy |
Priority | high | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.8.1 (published 2017-05) | Fixed in Version | v4.8.1 (published 2017-05) |
Clause Reference(s) | ES 201 873-9, chapter 8: Substitutions
For STF discussion |
Source (company - Author) | Devoteam, Thilo Lauer

Summary | 0007421: How to achieve full backward compatibility in case of element- and/or type-substitution

Description

We propose that compiling 'with element- and/or type-substitution enabled' the compiler shall be fully backward compatibe i.e. the compiler shall be able to compile suites containing templates (and field access paths) that were written for non-element / non-type substiution.
This means, that suites can be written, that can contain a mixture of "non-substituion" templates and "substitution" templates without any need to change older code in a testsuite. Even if both options (element and type substitution) are switched on older testsuites, that do not use substitution, can be compiled.
As far as we can see our proposal is a more general and more flexible solution as the one proposed in Mantis, CR7239: "Change element substitution generation rules to support backward compatibility"
Please see uploaded document "2016-02-26_Devoteam proposal for backward compatibility in case of element- and or type-substitution.docx" for details

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

Relationships

related to | 0007493 | closed | Gyorgy Rethy | Part 01: TTCN-3 Core Language | Add Wrapper-Union capability to the standard
related to | 0007239 | closed | Gyorgy Rethy | Part 09: Using XML with TTCN-3 | Change element substitution generation rules to support backward compatibility

Attached Files | 2016-02-26_Devoteam proposal for backward compatibility in case of element- and or type-substitution.docx (1,389,136) 01-03-2016 13:14 http://oldforge.etsi.org/mantis/file_download.php?file_id=3402&type=bug CR7421.docx (167,200) 19-08-2016 13:23 http://oldforge.etsi.org/mantis/file_download.php?file_id=3498&type=bug

Issue History
Date Modified | Username | Field | Change
01-03-2016 13:14 | Thilo Lauer | New Issue |
01-03-2016 13:14 | Thilo Lauer | File Added: 2016-02-26_Devoteam proposal for backward compatibility in case of element- and or type-substitution.docx |
18-03-2016 10:44 | Jacob Wieland - Spirent | Note Added: 0013897 |
08-04-2016 11:34 | Gyorgy Rethy | Note Added: 0013930 |
08-04-2016 11:34 | Gyorgy Rethy | Note Edited: 0013930 | bug_revision_view_page.php?bugnote_id=13930#r289
07-06-2016 13:34 | Gyorgy Rethy | Note Edited: 0013930 | bug_revision_view_page.php?bugnote_id=13930#r292
07-06-2016 13:36 | Gyorgy Rethy | Note Edited: 0013930 | bug_revision_view_page.php?bugnote_id=13930#r293
18-07-2016 10:20 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent
18-07-2016 10:20 | Jens Grabowski | Status | new => assigned
16-08-2016 16:32 | Jacob Wieland - Spirent | Relationship added | related to 0007493
17-08-2016 11:03 | Jacob Wieland - Spirent | Target Version | => v4.8.1 (published 2017-05)
19-08-2016 13:23 | Jacob Wieland - Spirent | File Added: CR7421.docx |
19-08-2016 13:24 | Jacob Wieland - Spirent | Note Added: 0014177 |
19-08-2016 13:24 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
19-08-2016 13:24 | Jacob Wieland - Spirent | Status | assigned => confirmed
19-08-2016 13:26 | Jacob Wieland - Spirent | Relationship added | related to 0007239
17-11-2016 10:10 | KristÃ³f Szabados | Note Added: 0014293 |
17-11-2016 10:10 | KristÃ³f Szabados | Status | confirmed => resolved
17-11-2016 10:10 | KristÃ³f Szabados | Fixed in Version | => v4.9.1 (published 2018-05)
17-11-2016 10:10 | KristÃ³f Szabados | Resolution | open => fixed
17-11-2016 14:18 | KristÃ³f Szabados | Note Added: 0014309 |
17-11-2016 14:18 | KristÃ³f Szabados | Status | resolved => feedback
17-11-2016 14:18 | KristÃ³f Szabados | Resolution | fixed => reopened
17-11-2016 14:19 | KristÃ³f Szabados | Status | feedback => resolved
17-11-2016 14:19 | KristÃ³f Szabados | Fixed in Version | v4.9.1 (published 2018-05) => v4.8.1 (published 2017-05)
17-11-2016 14:19 | KristÃ³f Szabados | Resolution | reopened => fixed
17-11-2016 14:21 | KristÃ³f Szabados | Status | resolved => feedback
17-11-2016 14:21 | KristÃ³f Szabados | Resolution | fixed => reopened
17-11-2016 14:21 | KristÃ³f Szabados | Status | feedback => resolved
17-11-2016 14:21 | KristÃ³f Szabados | Resolution | reopened => fixed
17-11-2016 14:21 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
13-12-2016 17:05 | Gyorgy Rethy | Note Added: 0014429 |
13-12-2016 17:05 | Gyorgy Rethy | Status | resolved => closed

Notes

(0013897)
Jacob Wieland - Spirent
18-03-2016 10:44

From my understanding, the proposal tries to introduce the following type compatibility (where WU is a union type marked as a special wrapper type):
a of type T is compatible to WU if a is compatible to the type of the first variant of WU
and
{ v := a } of type WU is compatible to type T if v is the first variant of WU and a is compatible to T
if type T again is a wrapper-union, this can lead to multiple implicit wrappings/unwrappings (as in the case of both XSD element-substitution and subtyping).
(Just added this as a reminder here fore later discussions)

(0013930)
Gyorgy Rethy
08-04-2016 11:34 (edited on: 07-06-2016 13:36)

It would be more appropriate and secure for the user to identify the default choice in the type definition explicitly (as opposed to have a rule based on the textual order of the union fields). Beside this the idea is good, gives huge flexibility to TTCN-3 code extensions. A corresponding Part-1 CR for default choice of union types should be created.

(0014177)
Jacob Wieland - Spirent
19-08-2016 13:24

please review

(0014293)
KristÃ³f Szabados
17-11-2016 10:10

looks good to me (now as CR 7493 is resolved)

(0014309)
KristÃ³f Szabados
17-11-2016 14:18

incorrect assignment at resolved

(0014429)
Gyorgy Rethy
13-12-2016 17:05

Added to draft V4.7.2