ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007473Part 01: TTCN-3 Core LanguageEditorialpublic09-08-2016 11:3816-12-2016 21:37
ReporterMartin Hauch 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Clause Reference(s)6.2.1
Source (company - Author) Devoteam - Martin Hauch
Summary0007473: Chapter 6.2.1 inconsitencies in optionial attribute "explicit omit"
DescriptionThe "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
TagsNo tags attached.
Relationships
related to 0007471closed Gyorgy Rethy editorial: inconsistency in the standard regarding partially initialized values 
related to 0007288closed Gyorgy Rethy Not described use cases for optional attribute 
Attached Filesdocx CR7288_CR7473_proposal.docx (160,152) 17-08-2016 10:16
http://oldforge.etsi.org/mantis/file_download.php?file_id=3468&type=bug
docx 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
docx 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
docx 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
docx 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 ModifiedUsernameFieldChange
09-08-2016 11:38Martin HauchNew Issue
15-08-2016 10:36Jens GrabowskiAssigned To => Kristóf Szabados
15-08-2016 10:36Jens GrabowskiStatusnew => assigned
15-08-2016 10:37Jens GrabowskiRelationship addedrelated to 0007471
15-08-2016 10:42Jens GrabowskiNote Added: 0014066
17-08-2016 05:26Kristóf SzabadosRelationship addedrelated to 0007288
17-08-2016 05:32Kristóf SzabadosNote Added: 0014120
17-08-2016 07:04Martin HauchNote Added: 0014121
17-08-2016 10:16Kristóf SzabadosFile Added: CR7288_CR7473_proposal.docx
17-08-2016 11:03Jacob Wieland - SpirentTarget Version => v4.9.1 (published 2017-05)
17-08-2016 22:19Kristóf SzabadosFile Added: CR7288_CR7473_proposal_v2.docx
18-08-2016 14:12Kristóf SzabadosFile Added: CR7288_CR7473_proposal_v3.docx
19-08-2016 10:31Kristóf SzabadosNote Added: 0014175
22-08-2016 08:02Martin HauchNote Added: 0014193
01-09-2016 11:21Kristóf SzabadosFile Added: CR7288_CR7473_proposal_v4.docx
01-09-2016 11:47Kristóf SzabadosNote Added: 0014199
14-11-2016 16:31Jens GrabowskiAssigned ToKristóf Szabados => Axel Rennoch
14-11-2016 16:31Jens GrabowskiStatusassigned => confirmed
15-11-2016 16:42Axel RennochFile Added: CR7288_CR7473_proposal_v5.docx
15-11-2016 16:43Axel RennochNote Added: 0014255
15-11-2016 16:44Axel RennochAssigned ToAxel Rennoch => Gyorgy Rethy
15-11-2016 16:44Axel RennochStatusconfirmed => assigned
15-11-2016 16:44Axel RennochStatusassigned => resolved
15-11-2016 16:44Axel RennochResolutionopen => fixed
12-12-2016 09:43Gyorgy RethyNote Added: 0014369
12-12-2016 09:43Gyorgy RethyNote Edited: 0014369bug_revision_view_page.php?bugnote_id=14369#r338
12-12-2016 09:44Gyorgy RethyAssigned ToGyorgy Rethy => Jens Grabowski
12-12-2016 09:44Gyorgy RethyNote Added: 0014370
12-12-2016 09:44Gyorgy RethyStatusresolved => feedback
12-12-2016 09:44Gyorgy RethyResolutionfixed => reopened
12-12-2016 09:49Gyorgy RethyNote Deleted: 0014370
12-12-2016 11:18Jacob Wieland - SpirentNote Added: 0014380
12-12-2016 11:20Jacob Wieland - SpirentNote Edited: 0014380bug_revision_view_page.php?bugnote_id=14380#r340
14-12-2016 13:45Gyorgy RethyNote Added: 0014437
14-12-2016 16:34Jacob Wieland - SpirentNote Added: 0014438
16-12-2016 21:33Gyorgy RethyNote Added: 0014455
16-12-2016 21:37Gyorgy RethyStatusfeedback => closed
16-12-2016 21:37Gyorgy RethyAssigned ToJens Grabowski => Gyorgy Rethy
16-12-2016 21:37Gyorgy RethyResolutionreopened => fixed
16-12-2016 21:37Gyorgy RethyFixed 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.