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

ID | Project | Category | View Status | Date Submitted | Last Update
0006411 | Part 01: TTCN-3 Core Language | Clarification | public | 16-01-2013 11:03 | 23-09-2014 16:01

Reporter | Thilo Lauer |
Assigned To | Gyorgy Rethy |
Priority | urgent | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.4.1 (published 2012-04) |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.6.2 (interim 2014) |
Clause Reference(s) | 15.5 Modified templates
Source (company - Author) | Devoteam - Thilo Lauer

Summary | 0006411: Example to clarify Modified Template semantics

Description

Please add this example as clarification of the semantic of modified templates for of-type-fields:
type record of integer MyIntegerList_Type;
type record MyRecord_Type {
MyIntegerList_Type intList
};
template (value) MyRecord_Type cs_MyRecord := { intList := {1, 2, 3} };
template (value) MyRecord_Type cds_MyRecordModified1 modifies cs_MyRecord :=
{ intList := { 42 } };
template (value) MyRecord_Type cds_MyRecordModified2 modifies cs_MyRecord :=
{ intList := { [0] := 42 } };
// result:
// cds_MyRecordModified1.intList has value : {42}
// cds_MyRecordModified2.intList has value : {42, 2, 3}

Steps To Reproduce |

Additional Information

Our previous interpretation of the semantics of modified templates was, that we are in a modification context, where values are modified, but not completely replaced, e.g.:
template (value) MyRecord_Type cds_MyRecordModified1 modifies cs_MyRecord :=
{ intList := { 42 } };
// results also to:
// cds_MyRecordModified1.intList has value : {42, 2, 3}
But meanwhile we have changed our semantic to:
// cds_MyRecordModified1.intList has value : {42}

Tags | No tags attached.

Relationships

related to | 0006429 | closed | Gyorgy Rethy | modifies of 'record of' fields still seems to be ambiguous

Attached Files

modified_templates_4ETSI.ttcn (2,895) 27-08-2013 08:41
http://oldforge.etsi.org/mantis/file_download.php?file_id=2855&type=bug
CR6429_CR6411_resolution_v1.doc (88,576) 28-08-2013 10:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2864&type=bug
CR6429_CR6411_resolution_v2.doc (88,576) 29-08-2013 09:57
http://oldforge.etsi.org/mantis/file_download.php?file_id=2873&type=bug
CR6429_CR6411_resolution_v2-2.docx (60,220) 19-06-2014 17:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3064&type=bug

Issue History
Date Modified | Username | Field | Change
16-01-2013 11:03 | Thilo Lauer | New Issue |
16-01-2013 11:03 | Thilo Lauer | Clause Reference(s) | => 15.5 Modified templates
16-01-2013 11:03 | Thilo Lauer | Source (company - Author) | => Devoteam - Thilo Lauer
08-07-2013 15:50 | Jens Grabowski | Status | new => assigned
08-07-2013 15:50 | Jens Grabowski | Assigned To | => Gyorgy Rethy
08-07-2013 15:51 | Jens Grabowski | Relationship added | related to 0006429
08-07-2013 18:17 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2014-06)
12-07-2013 14:48 | Gyorgy Rethy | Note Added: 0011579 |
12-07-2013 14:50 | Gyorgy Rethy | Note Edited: 0011579 |
26-08-2013 12:19 | Gyorgy Rethy | Note Added: 0011591 |
26-08-2013 12:20 | Gyorgy Rethy | Note Edited: 0011591 |
26-08-2013 14:12 | Jacob Wieland - Spirent | Note Added: 0011596 |
26-08-2013 17:10 | Gyorgy Rethy | File Added: modified_templates_4ETSI.ttcn |
26-08-2013 17:10 | Gyorgy Rethy | Note Added: 0011604 |
27-08-2013 08:40 | Gyorgy Rethy | File Deleted: modified_templates_4ETSI.ttcn |
27-08-2013 08:41 | Gyorgy Rethy | File Added: modified_templates_4ETSI.ttcn |
27-08-2013 09:13 | Gyorgy Rethy | Note Added: 0011605 |
27-08-2013 10:45 | Jacob Wieland - Spirent | Note Added: 0011606 |
28-08-2013 10:34 | Gyorgy Rethy | File Added: CR6429_CR6411_resolution_v1.doc |
28-08-2013 10:35 | Gyorgy Rethy | Note Added: 0011615 |
28-08-2013 10:35 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
28-08-2013 11:30 | Jacob Wieland - Spirent | Note Added: 0011623 |
28-08-2013 11:31 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
28-08-2013 11:31 | Jacob Wieland - Spirent | Status | assigned => confirmed
29-08-2013 09:57 | Gyorgy Rethy | Note Added: 0011632 |
29-08-2013 09:57 | Gyorgy Rethy | File Added: CR6429_CR6411_resolution_v2.doc |
29-08-2013 09:57 | Gyorgy Rethy | Status | confirmed => assigned
29-08-2013 09:57 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
29-08-2013 09:58 | Gyorgy Rethy | Note Edited: 0011632 |
29-08-2013 14:14 | Jacob Wieland - Spirent | Note Added: 0011639 |
29-08-2013 14:14 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
30-08-2013 09:42 | Gyorgy Rethy | Note Added: 0011649 |
30-08-2013 09:42 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
30-08-2013 09:43 | Gyorgy Rethy | Status | assigned => confirmed
30-08-2013 13:57 | Jacob Wieland - Spirent | Note Added: 0011662 |
07-10-2013 12:27 | Jacob Wieland - Spirent | Status | confirmed => assigned
07-10-2013 12:27 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
08-10-2013 16:23 | Gyorgy Rethy | Note Added: 0011706 |
08-10-2013 16:23 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
10-10-2013 13:30 | Jacob Wieland - Spirent | Note Added: 0011751 |
10-10-2013 13:32 | Jacob Wieland - Spirent | Note Added: 0011752 |
08-04-2014 16:50 | Gyorgy Rethy | Target Version | v4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
19-06-2014 14:29 | Gyorgy Rethy | Assigned To | Jens Grabowski => Axel Rennoch
19-06-2014 14:30 | Gyorgy Rethy | Note Added: 0012146 |
19-06-2014 17:01 | Axel Rennoch | File Added: CR6429_CR6411_resolution_v2-2.docx |
19-06-2014 17:02 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
19-06-2014 17:03 | Axel Rennoch | Note Added: 0012160 |
19-06-2014 17:03 | Axel Rennoch | Status | assigned => confirmed
27-06-2014 13:44 | Gyorgy Rethy | Priority | normal => urgent
23-09-2014 16:01 | Gyorgy Rethy | Note Added: 0012216 |
23-09-2014 16:01 | Gyorgy Rethy | Status | confirmed => closed
23-09-2014 16:01 | Gyorgy Rethy | Resolution | open => fixed
23-09-2014 16:01 | Gyorgy Rethy | Fixed in Version | => v4.6.2 (interim 2014)

Notes

(0011579)
Gyorgy Rethy
12-07-2013 14:48 (edited on: 12-07-2013 14:50)

Examples in the dscription part are correct. The CR is handled together with CR6429, please see the resolution there.

(0011591)
Gyorgy Rethy
26-08-2013 12:19 (edited on: 26-08-2013 12:20)

Yes Thilo, your new interpretation is correct.
In general, the rules of modifying record/set-s and record_of/set_of-s is underspecified. What is defined by the text or by an example:
- in records/sets: the fields specified are replaced, fields not specified are left unchanged; shall be true for both assignment and list notations as the text doesn't specify different rules for different types of notations ($15.5 semantic description 2nd paragraph, and for the assignment notation: example 1).
examples:
type record R { integer a, integer b }
template R t_r1 := { a:= 1, b:= 2 }
template R t_r2 modifies t_r1 := { a:= 42 } // results { 42, 2 }
template R t_r3 modifies t_r1 := { a:= 42, b:= - } // results { 42, 2 }
template R t_r4 modifies t_r1 := { 42 } // results { 42, 2 }
template R t_r5 modifies t_r1 := { 42,- } // results { 42, 2 }
template R t_r6 modifies t_r1 := { b:= 42 } // results { 1, 42 }
template R t_r7 modifies t_r1 := { -,42 } // results { 1, 42 }
All of the above examples comply with the existing text, but examples for list notation are missing.
-in record_of/set_of-s:
Rule is given explicitly to change individual elements: $15.5 semantic description 3rd paragraph, example 2.
No explicit rule is given when complete record_of/set_of is defined using list notation (current text: "When individual values of a modified template or a modified template field of record of type wished to be changed..." can be understood as a hint that in other cases the whole value is replaced, but this is not formulated explicitly).
In this case, I think both CR6411 and CR6429 are correct, a "complete" record/set, i.e. without index notation should replace the whole parent record/set_of, otherwise there is no other way to replace the whole parent value.
However, this raises the question of t_r4 above. For consistency this should be the rule for records/sets as well: in both cases list notation should be considered as a complete value, any kind of notation with ":=" changes just the identified fields or elements only.
But this would be a BACKWARD INCOMPATIBLE CHANGE that needs to be agreed with users and tool vendors!
- no explicit rule is given for other structured types: union and enumerated: the rule is trivial as they always contain one chosen field/enum.value, this will simply replace its parent.

(0011596)
Jacob Wieland - Spirent
26-08-2013 14:12

Since there is no clarification required or needed for record/set types (without of), I don't think that we should introduce a backward incompatible change for them.

(0011604)
Gyorgy Rethy
26-08-2013 17:10

See examples in modified_templates_4ETSI.ttcn

(0011605)
Gyorgy Rethy
27-08-2013 09:13

In this case at least we shall be clear and explicit about the semantics when using different kind of notations and shall explicitly notify (warn) the users about the semantic difference between the record/set and ~of-s when using a value list notation.

(0011606)
Jacob Wieland - Spirent
27-08-2013 10:45

Agreed, this should be done in a NOTE (and the example, I guess)

(0011615)
Gyorgy Rethy
28-08-2013 10:35

Draft resolution text is in CR6429_CR6411_resolution_v1.doc. Pls. review.

(0011623)
Jacob Wieland - Spirent
28-08-2013 11:30

I still have issue with the formulation
"then the specified matching symbol replaces the one specified in the parent template"
because what we actually mean is that it *modifies* the matching symbol in the parent template, i.e. replacement only occurs for non-structured and enumerated types while for structured, replacement means recursive modification.
Since modification for non-structured and enumerated types is already defined as replacement, I think we are safe to change this part to:
"then the specified matching symbol modifies the one specified in the parent template"

(0011632)
Gyorgy Rethy
29-08-2013 09:57 (edited on: 29-08-2013 09:58)

Modifies is a dangerous word as it can be misunderstood as modifying the matching symbol itself, e.g.
template MyRecord t_base := { a:= true, b:=(1,2,3,4)}
template MyRecord t_mod modifies t_base := { b:=(5,6,7,8)}
//could be misinterpreted as t_mod containing {true, (1,2,3,4,5,6,7,8)},
//as it just modifies field b of t_base, not replaces it...
I propose rather to specify precisely *what* is replaced: replaces the one specified in the corresponding field of the parent template.
See CR6429_CR6411_resolution_v2.doc

(0011639)
Jacob Wieland - Spirent
29-08-2013 14:14

Still, I don't understand the text in the way which corresponds to my understanding of the intention of the text.
The sentence
"For templates, template fields and elements of record and set types, if a record or set field and its corresponding matching symbol is specified in the modified template, then the specified matching symbol replaces the one specified in the corresponding field of the parent template".
for me implies, that if the "matching symbol" is an underspecified value which is a field assignment notation, this underspecified value would *replace* the one in the parent and not simply *modify* those fields in the parent field which are specified (recursively).
The only time, real replacement actually occurs is for non-compound-expression matching mechanisms.

(0011649)
Gyorgy Rethy
30-08-2013 09:42

The sentence is talking about one single field of a record or set. If this field is specified AND no dash on the RHS, the content of the given field replaces the content of the same field in the parent template.
Actually, reading through the sentence several times during CR resolution, I cannot read it another way. So, pls. formulate a sentence you think expresses we want to say here.
(PS: maybe the beginning of the sentence is too complicated, it could be just ""For record and set types, if a record or set field and its corresponding matching symbol ..."

(0011662)
Jacob Wieland - Spirent
30-08-2013 13:57

The problem is, if the "single field of a record or set" is again a structured expression. Then *replacement* (which normally means fully replacing the old with the new, i.e. not keeping anything from the old) is in actuality meant as *modification* for the field, i.e. only those fields in the sub-structure of the field are modifying the fields of the sub-structure of the parent field.
In my opinion, using *modifies* (or *recursively modifies*) instead of *replaces* makes the issue totally clear as for non-structured values, *modifies* is already defined as full replacement (in the paragraph before).

(0011706)
Gyorgy Rethy
08-10-2013 16:23

Assigned to Jens for proof-reading -> CR6429_CR6411_resolution_v2.doc

(0011751)
Jacob Wieland - Spirent
10-10-2013 13:30

Somehow, the more often I read the description/definition of the modification algorithm, the less I can see the connection to my understanding of the modifies construct (and what the examples describe).
In the algorithm, always replacement is used where modification is meant. Since these are semantically different things, I think we have to clarify this so that the actual algorithm is reflected.
Basically, there are the following cases in this recursive algorithm:
0) a field to be modified is not initialized in the parent -> replacement
1) a matching symbol which is not a compound expression shall modify an existing field in the parent -> replacement
2) a compound expression shall modify an existing field in the parent
-> recursion: the elements/fields of the compound expression modify their respective counterparts in the parent.
For 2, there then are the special cases for list notation used for record of and set of fields regarding additional truncation of the parent.

(0011752)
Jacob Wieland - Spirent
10-10-2013 13:32

In the proposed resolution, there is a typo: corresping

(0012146)
Gyorgy Rethy
19-06-2014 14:30

STF discussion: assigned to Axel, together with 6429 to check which text reads more easily and unambiguously and add an example.

(0012160)
Axel Rennoch
19-06-2014 17:03

replace "matching symbol" by "matching mechanism" and correction of two typos

(0012216)
Gyorgy Rethy
23-09-2014 16:01

Added to master copy of V4.6.2