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

ID | Project | Category | View Status | Date Submitted | Last Update
0007473 | Part 01: TTCN-3 Core Language | Editorial | public | 09-08-2016 11:38 | 16-12-2016 21:37

Reporter | Martin Hauch |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.9.1 (published 2017-05) | Fixed in Version | v4.9.1 (published 2017-05) |
Clause Reference(s) | 6.2.1
Source (company - Author) | Devoteam - Martin Hauch

Summary | 0007473: Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit"

Description

The "implicit explicit omit" rule applies also to variables, even if the optional attribute is not allowed for variables. There are 2 paragraphs in 6.2.1 which are not coherent, especially when reassigning variables:
"
Paragraph 1:
When using the value list notation, all fields in the structure shall be specified either with a value, the not used symbol "-" or the omit keyword. The omit keyword shall only be used for optional fields. Its result is that the given field is not present in the given value. The first component of the list (a value, a "-" or omit) is associated with the first field, the second list component is associated with the second field, etc. No empty assignment is allowed (i.e. two commas, the second immediately following the first or only with white space between them). Fields or elements to be left unchanged shall be explicitly skipped in the list by using the not-used-symbol "-".
Paragraph 2:
When the value list notation is used in a scope, where the optional attribute is implicitly or explicitly set to "explicit omit, already initialized fields or elements left without an associated component in a value list notation (i.e. at the end of a value ) are becoming uninitialized. In this way, a value with initialized fields or elements can be made empty by using an empty pair of curly brackets ("{}").
"
Paragraph 1 says, ALL fields shall be specified. Paragraph 2 allows to leave out values if the optional attribute is implicitly set to explicit omit, which is the case in Paragraph 1!
Also, paragraph 2 leads to the conclusion that if we have mandatory fields in the value, using "{}" to "clear" a value affects mandatory fields, whereas the "optional" attribute should only be related to optional fields in my opinion. This is very confusing and has to be clarified.
As mentioned in CR7471 the assignment of sub-fields of a variable could be done by modified templates or
myVar.field1[3]:= { ... }

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

Relationships

related to | 0007471 | closed | Gyorgy Rethy | editorial: inconsistency in the standard regarding partially initialized values
related to | 0007288 | closed | Gyorgy Rethy | Not described use cases for optional attribute

Attached Files

CR7288_CR7473_proposal.docx (160,152) 17-08-2016 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3468&type=bug
CR7288_CR7473_proposal_v2.docx (159,887) 17-08-2016 22:19
http://oldforge.etsi.org/mantis/file_download.php?file_id=3482&type=bug
CR7288_CR7473_proposal_v3.docx (163,514) 18-08-2016 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=3489&type=bug
CR7288_CR7473_proposal_v4.docx (171,981) 01-09-2016 11:21
http://oldforge.etsi.org/mantis/file_download.php?file_id=3508&type=bug
CR7288_CR7473_proposal_v5.docx (172,677) 15-11-2016 16:42
http://oldforge.etsi.org/mantis/file_download.php?file_id=3527&type=bug

Issue History
Date Modified | Username | Field | Change
09-08-2016 11:38 | Martin Hauch | New Issue |
15-08-2016 10:36 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
15-08-2016 10:36 | Jens Grabowski | Status | new => assigned
15-08-2016 10:37 | Jens Grabowski | Relationship added | related to 0007471
15-08-2016 10:42 | Jens Grabowski | Note Added: 0014066 |
17-08-2016 05:26 | KristÃ³f Szabados | Relationship added | related to 0007288
17-08-2016 05:32 | KristÃ³f Szabados | Note Added: 0014120 |
17-08-2016 07:04 | Martin Hauch | Note Added: 0014121 |
17-08-2016 10:16 | KristÃ³f Szabados | File Added: CR7288_CR7473_proposal.docx |
17-08-2016 11:03 | Jacob Wieland - Spirent | Target Version | => v4.9.1 (published 2017-05)
17-08-2016 22:19 | KristÃ³f Szabados | File Added: CR7288_CR7473_proposal_v2.docx |
18-08-2016 14:12 | KristÃ³f Szabados | File Added: CR7288_CR7473_proposal_v3.docx |
19-08-2016 10:31 | KristÃ³f Szabados | Note Added: 0014175 |
22-08-2016 08:02 | Martin Hauch | Note Added: 0014193 |
01-09-2016 11:21 | KristÃ³f Szabados | File Added: CR7288_CR7473_proposal_v4.docx |
01-09-2016 11:47 | KristÃ³f Szabados | Note Added: 0014199 |
14-11-2016 16:31 | Jens Grabowski | Assigned To | KristÃ³f Szabados => Axel Rennoch
14-11-2016 16:31 | Jens Grabowski | Status | assigned => confirmed
15-11-2016 16:42 | Axel Rennoch | File Added: CR7288_CR7473_proposal_v5.docx |
15-11-2016 16:43 | Axel Rennoch | Note Added: 0014255 |
15-11-2016 16:44 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
15-11-2016 16:44 | Axel Rennoch | Status | confirmed => assigned
15-11-2016 16:44 | Axel Rennoch | Status | assigned => resolved
15-11-2016 16:44 | Axel Rennoch | Resolution | open => fixed
12-12-2016 09:43 | Gyorgy Rethy | Note Added: 0014369 |
12-12-2016 09:43 | Gyorgy Rethy | Note Edited: 0014369 | bug_revision_view_page.php?bugnote_id=14369#r338
12-12-2016 09:44 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
12-12-2016 09:44 | Gyorgy Rethy | Note Added: 0014370 |
12-12-2016 09:44 | Gyorgy Rethy | Status | resolved => feedback
12-12-2016 09:44 | Gyorgy Rethy | Resolution | fixed => reopened
12-12-2016 09:49 | Gyorgy Rethy | Note Deleted: 0014370 |
12-12-2016 11:18 | Jacob Wieland - Spirent | Note Added: 0014380 |
12-12-2016 11:20 | Jacob Wieland - Spirent | Note Edited: 0014380 | bug_revision_view_page.php?bugnote_id=14380#r340
14-12-2016 13:45 | Gyorgy Rethy | Note Added: 0014437 |
14-12-2016 16:34 | Jacob Wieland - Spirent | Note Added: 0014438 |
16-12-2016 21:33 | Gyorgy Rethy | Note Added: 0014455 |
16-12-2016 21:37 | Gyorgy Rethy | Status | feedback => closed
16-12-2016 21:37 | Gyorgy Rethy | Assigned To | Jens Grabowski => Gyorgy Rethy
16-12-2016 21:37 | Gyorgy Rethy | Resolution | reopened => fixed
16-12-2016 21:37 | Gyorgy Rethy | Fixed in Version | => v4.9.1 (published 2017-05)

Notes

(0014066)
Jens Grabowski
15-08-2016 10:42

STF discussion: Paragraph 1: Makes only sense for "records" Paragraph 2: Makes only sense for "record of"

(0014120)
KristÃ³f Szabados
17-08-2016 05:32

CR7288 we also changed the example of section 6.2.1 where implicit/explicit omit is attached to variables, so that they are attached to constants.

(0014121)
Martin Hauch
17-08-2016 07:04

I agree, that paragraph 2 makes only sens for "record of", but it is defined in chapter "Record type and values" and all examples in this chapter are records. I also think the optional attribute is only allowed for record-values (not record- or set-of-values). So paragraph 2 either must be deleted or moved to chapter 6.2.3 "Records and sets of single types".

(0014175)
KristÃ³f Szabados
19-08-2016 10:31

STF discussion:
- even in partial assignment cases fields in the assignment notation should be unique (section 6.2.0 2nd paragraph).
- the same for index notation.
- value list notation used on record/set type changes only the values listed in scopes where "optional omit" is set explicitly or implicitly
- The first sentence of 15.5 (starting with "Normally, ") should be deleted as it does not introduce a new constraint.

(0014193)
Martin Hauch
22-08-2016 08:02

I think value list notation needs clarification: In my opinion value list needs complete value-assignment using '-' to let a field uninitialized or unchanged. Exception in case of "optional implicit omit", remaining optional fields at the end of the type definition (all remaining fields are optional), can be left out, if wished to be omitted.
The first sentence of 15.5 should not be removed, as it clarifies that a modified template only changes values/matching-mechanisms for parts of a completely defined base-template. The base constraint is a complete assigned template. Templates need to be complete assigned, because they are used for sending and receiving (first sentence chapter 15 "Declaring templates".
Remarks to changes in CR7288_CR7473_proposal_v3-1:
Example 8 in chapter 6.2.1:
const R c_x3 := { 1, -, 2 }
// after the assignment c_x3 contains { 1, <undefined>, 2, <undefined>, <undefined>}
const R c_x4 := c_x3 with { optional "implicit omit" }
// after the assignment c_x4 contains { 1, omit, 2, omit, omit }
Definition of c_x3 is not correct, because 6.2.1 says: "When using the value list notation, all fields in the notation shall be specified." There is no optional attribute "implicit omit" set. So, this line should look like
const R c_x3 := { 1, -, 2, -, - };
Remarks to examples in chapter 27.7:
Templates definitions must be comlete in my opininion. Therefore i think most of the examples are not correct. Template are used for send/receive (as chapter 15 first sentence says) and this is only possible with complete defined templates!

(0014199)
KristÃ³f Szabados
01-09-2016 11:47

Sorry for the delay; uploaded the text version that is in line with the STF decision.
The first sentence from 15.5 is removed as it does not add to or take away from the standard.
It is read (and can be mentally extended with): normally, you should do something like this (at other times, other kinds of usages are fine too)
Maybe we could add a note to show some generic programming best practices, something like this:
"Those templates which will be used directly in send/receive operations shall be completely initialized, otherwise they would result in test case error at the time of the send/receive operation.
On the other hand there are cases where some templates must, by design, never reach send/receive operations directly. For example partially initialized templates are to be used when one field must hold some unique identifier, that is not known statically. In these cases choosing any dummy number would run the risk of directing future tests, where the template is used and the field not overwritten, on unexpected execution paths. This would result in tests not testing what they were meant to be, and result in large debugging and maintenance cost where the problems is realised. Partially initialized templates can still be used to initialize other templates or as bases of modified templates; which have the uninitilized fields filled in, and can be used in send/receive operations"

(0014255)
Axel Rennoch
15-11-2016 16:43

just some small minor editorial modifications

(0014369)
Gyorgy Rethy
12-12-2016 09:43

Implemented the current v5 version of the resolution. During this I have noticed an issue.
In clause 6.2.1.0 General, in the paragraph following example 4, is written
"... The omit keyword shall only be used for optional fields. Its result is that the given field is not present in the given value. ..."
The 2nd sentence is misleading as the field is not present in the ENCODED value, but present and perfectly defined in the abstract TTCN-3 value. I can see this type of misunderstanding at users several times.
My proposals:
a) delete the sentence
b) move the sentence to a note and adding "...given field is not present in the encoded instance of the given value."
What do you think?

(0014380)
Jacob Wieland - Spirent
12-12-2016 11:18 (edited on: 12-12-2016 11:20)

the concept of present-ness is tightly coupled with the optionality of fields, so I think it is perfectly alright stated as is. An optional field whose DEFINITION syntactically is present, but defined using omit is not present in the template(present) sense, i.e. ispresent() will yield false. Maybe this should be clarified in the definitions section, if not already clear enough.
So, even unencoded, abstract TTCN-3 values can have optional field which are not present, not just encoded ones.

(0014437)
Gyorgy Rethy
14-12-2016 13:45

Seems we may have different understanding here.
I think that
template integer mw_int := omit;
is an existing definition, i.e. present and defined at the abstract TTCN-3 level, it can be referenced in other definitions.
To my view the same is true for optional fields:
type record MyRec {
integer int optional
}
template MyRec mw_rec := {
int := omit
}
is not an empty record, but a record with one field, which has the omit property assigned (e.g. in PER it will even be encoded as a single "0" bit!); also isbound(mw_rec.int) will return true!
At the abstract TTCN-3 level both the above template mw_int and template field mw_rec.int are reference-able and bound, therefore they shall exist (i.e. shall be present and set to the "special value" omit).
PS: ispresent() is just a name given by us, the human meaning of a name doesn't define its semantics.

(0014438)
Jacob Wieland - Spirent
14-12-2016 16:34

Using that kind of definition of present-ness, pretty much everything is present, even the void, because that also can be referenced. Thus, such a definition is useless.
Throughout the standard, we have a very clear understanding what 'being present' means in the context of an optional field of a value (i.e. it is initialized and not set to omit) or a template (it is initialized with a matching mechanism that does not match omit). This is captured by the semantics of the functions ispresent() and also by the template(present) restriction.
To summarize: in my understanding explicitly or implicitly omitted fields are definitely not present in the value, they may be present in some form in the encoded value (i.e. their not-present-ness can take up some space in the encoded value), and of course they are present in some form also in the decoded value (i.e. represented by some data in the memory that captures the non-presentness), but from the TTCN-3 point of view, and that is what we are talking about in that section, they are not.

(0014455)
Gyorgy Rethy
16-12-2016 21:33

OK, it was just a side note for a possible last minute clarification; as the draft need to be submitted, I don't think we need to go into or have time for a discussion.