Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
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) 
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]:= { ... }
TagsNo tags attached.
Clause Reference(s)6.2.1
Source (company - Author) Devoteam - Martin Hauch
Attached Filesdocx file icon CR7288_CR7473_proposal.docx [^] (160,152 bytes) 17-08-2016 10:16
docx file icon CR7288_CR7473_proposal_v2.docx [^] (159,887 bytes) 17-08-2016 22:19
docx file icon CR7288_CR7473_proposal_v3.docx [^] (163,514 bytes) 18-08-2016 14:12
docx file icon CR7288_CR7473_proposal_v4.docx [^] (171,981 bytes) 01-09-2016 11:21
docx file icon CR7288_CR7473_proposal_v5.docx [^] (172,677 bytes) 15-11-2016 16:42

- Relationships
related to 0007471closedGyorgy Rethy editorial: inconsistency in the standard regarding partially initialized values 
related to 0007288closedGyorgy Rethy Not described use cases for optional attribute 

-  Notes
(0014066)
Jens Grabowski (manager)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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 (developer)
15-11-2016 16:43

 just some small minor editorial modifications
(0014369)
Gyorgy Rethy (reporter)
12-12-2016 09:43
edited on: 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 (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
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.

- 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 View Revisions
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 View Revisions
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)

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker