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

ID | Project | Category | View Status | Date Submitted | Last Update
0008009 | Part 01: TTCN-3 Core Language | Technical | public | 01-03-2021 10:36 | 23-11-2021 15:40

Reporter | Tomas Urban |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version |  |
Clause Reference(s) | 6.2.1.1
Source (company - Author) | Elvior OÜ

Summary | 0008009: Missing rule for no optional attribute (or default value of the optional attribute)

Description

TTCN-3 core language standard defines no implicit value of the optional attribute. The rules are usually composed in such a way that there are common basic rules that always apply and then specific rules for cases when either "explicit omit" or "implicit omit" is defined. E.g. rules on list notation of record values defined in 6.2.1.0 say that "Fields not mentioned are implicitly left uninitialized." This is followed by rules for "explicit omit" which basically say the same and rules for "implicit omit" that define a different behaviour.
Unfortunately, this is not always the case. E.g. rules for expansion of record values defined in 6.2.1.1.a have only two alternatives: one for "explicit omit" and the other for "implicit omit". With no default value of the optional attribute it is unclear what should happen in this case. Our tool has always used "explicit omit" for these cases, but we have recently encountered a situation when the testing environment was made in other tool which used "implicit omit".
Proposal:
Option 1: Add the following rule to the chapter 27: If no optional attribute is specified or its value is different than the standardized strings (i.e. "explicit omit", "implicit omit"), rules for "explicit omit" apply.
Option 2: Change some rules in 6.2.1.0, 6.2.1.1.a and 27:
[6.2.1.0 - assignment list notation]
When the assignment notation is used in a scope, where the optional attribute is either unspecified or set to "explicit omit", optional and mandatory fields, not directly referred to in the notation shall remain unchanged. When optional fields of variables are not assigned explicitly, they are uninitialized (i.e. the optional attribute shall not have any effect on variables as described in clause 27.7 restriction a)).
[6.2.1.0 - value list notation]
When using value list notation in a scope where the optional attribute is either unspecified or set to "explicit omit", all remaining fields at the end of the type definition, missing from the value list notation, are left unchanged.
[6.2.1.1.a]
When expanding a value or value field of record type, the subfield referenced in the dot notation shall be set to present and all unreferenced mandatory subfields shall be left uninitialized; when the assignment is used in a scope where the optional attribute is either unspecified or equal to "explicit omit", all unreferenced optional subfields shall be left undefined. When the assignment is used in a scope where the optional attribute is equal to "implicit omit", all unreferenced optional subfields shall be set to omit.
[27]
Add the following rule: If the optional attribute has a different value than the standardized string (i.e. "explicit omit", "implicit omit"), it is considered as if the optional attribute was unspecified.

Steps To Reproduce |
Additional Information | Note: There's a danger that when opting for "explicit omit" as proposed would lead to backwards incompatibility if some tools use "implicit omit" as the default option.
Tags | No tags attached.
Relationships |
Attached Files | CR8009.docx (172,161) 07-09-2021 14:30 http://oldforge.etsi.org/mantis/file_download.php?file_id=4003&type=bug

Issue History
Date Modified | Username | Field | Change
01-03-2021 10:36 | Tomas Urban | New Issue |
01-03-2021 10:38 | Tomas Urban | Description Updated | bug_revision_view_page.php?rev_id=547#r547
01-03-2021 10:40 | Tomas Urban | Description Updated | bug_revision_view_page.php?rev_id=548#r548
06-09-2021 10:22 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent
06-09-2021 10:22 | Jens Grabowski | Status | new => assigned
07-09-2021 14:30 | Jacob Wieland - Spirent | File Added: CR8009.docx |
07-09-2021 14:31 | Jacob Wieland - Spirent | Note Added: 0015946 |
07-09-2021 14:31 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
07-09-2021 14:31 | Jacob Wieland - Spirent | Status | assigned => confirmed
09-09-2021 07:01 | Tomas Urban | Note Added: 0015960 |
09-09-2021 07:01 | Tomas Urban | Status | confirmed => resolved
09-09-2021 07:01 | Tomas Urban | Resolution | open => fixed
09-09-2021 07:01 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
23-11-2021 15:40 | Jens Grabowski | Note Added: 0016100 |
23-11-2021 15:40 | Jens Grabowski | Status | resolved => closed

Notes

(0015946)
Jacob Wieland - Spirent
07-09-2021 14:31

Please review (I have chosen to word it using 'implicitly' so it aligns with the other places that mention this way of definition)

(0015960)
Tomas Urban
09-09-2021 07:01

The proposed resolution addresses the issues raised in the CR and can be added to the next version of the core language specification.

(0016100)
Jens Grabowski
23-11-2021 15:40

implemented