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

ID | Project | Category | View Status | Date Submitted | Last Update
0005347 | Part 01: TTCN-3 Core Language | Clarification | public | 14-09-2009 11:15 | 01-07-2011 15:58

Reporter | Gyorgy Rethy |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.1.1 (published 2009-06) |
Target Version | v4.3.2 (interim 2011) | Fixed in Version | v4.3.2 (interim 2011) |
Clause Reference(s) | 6.2.1.1, 6.2.2.1, 6.2.5.1
Source (company - Author) | L.M.Ericsson

Summary | 0005347: Subtyping rules when referencing fields of structured types

Description

This is not covered by the current text. Proposed rules are:
-when referencing a field, the type constraint of the field shall be part of the new type; example:
type record R { x integer optional (1,2), y integer optional (1,2)}
type R.x X //=> R.x is defining the type integer X (1,2)
- when referencing a field, any type constraint of the structured type shall be ignored; examples:
1)
type record R1 { x integer optional }
type R1 R2 ( {}, { x := omit }, { x := 4 }, { x := 5 } )
type R2.x X2;
If the constraint of the record type would be "transformed back" to constraint of the referenced field, X2 would be:
X2 -> type integer X2 (<empty>, omit, 4, 5)
that is not a valid type definition.
2)If the constraint of the record type is "transformed back" to a constraint of the referenced field:
type record R3 { x integer optional, y integer optional } ({x:=1,y:=2}, {x:= 2,y:=1}, {x:=omit, y:=2}, {x:=1, y:=omit})
R3 should have the same value space as R. But it does not have.

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

Attached Files

CR5347.zip (735,241) 03-09-2010 13:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2442&type=bug
CR5347_resolution_v2.doc (110,592) 25-05-2011 14:38
http://oldforge.etsi.org/mantis/file_download.php?file_id=2485&type=bug
CR5347_resolution_v3.doc (71,680) 25-05-2011 14:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2486&type=bug
CR5347_resolution_v4.doc (73,216) 01-07-2011 15:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2551&type=bug

Issue History
Date Modified | Username | Field | Change
14-09-2009 11:15 | Gyorgy Rethy | New Issue |
14-09-2009 11:15 | Gyorgy Rethy | Status | new => assigned
14-09-2009 11:15 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
14-09-2009 11:15 | Gyorgy Rethy | Clause Reference(s) | => 6.2.1.1, 6.2.2.1, 6.2.5.1
14-09-2009 11:15 | Gyorgy Rethy | Source (company - Author) | => L.M.Ericsson
07-12-2009 14:37 | Ina Schieferdecker | Target Version | => Edition 4.2.1 (not yet published)
04-01-2010 13:49 | Ina Schieferdecker | Note Added: 0009156 |
04-01-2010 13:49 | Ina Schieferdecker | Target Version | Edition 4.2.1 (not yet published) => Edition 5.1.1 (not yet published)
22-03-2010 17:23 | Gyorgy Rethy | Assigned To | Ina Schieferdecker =>
22-03-2010 17:23 | Gyorgy Rethy | Status | assigned => new
23-03-2010 12:50 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
23-03-2010 12:50 | Gyorgy Rethy | Status | new => assigned
23-03-2010 15:37 | Jacob Wieland - Spirent | Note Added: 0009265 |
24-03-2010 11:04 | Gyorgy Rethy | Note Added: 0009274 |
24-03-2010 11:06 | Gyorgy Rethy | Note Edited: 0009274 |
24-03-2010 12:21 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
03-09-2010 13:11 | Jacob Wieland - Spirent | File Added: CR5347.zip |
03-09-2010 13:14 | Jacob Wieland - Spirent | Note Added: 0009711 |
03-09-2010 13:15 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
03-09-2010 13:15 | Jacob Wieland - Spirent | Status | assigned => resolved
03-09-2010 13:15 | Jacob Wieland - Spirent | Fixed in Version | => Edition 4.3.1 (not yet published)
03-09-2010 13:15 | Jacob Wieland - Spirent | Resolution | open => fixed
14-12-2010 15:29 | Ina Schieferdecker | Note Added: 0009970 |
14-12-2010 15:29 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Gyorgy Rethy
14-12-2010 15:29 | Ina Schieferdecker | Fixed in Version | Edition 4.3.1 (not yet published) =>
14-12-2010 15:29 | Ina Schieferdecker | Target Version | Edition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
25-05-2011 11:39 | Gyorgy Rethy | Status | resolved => feedback
25-05-2011 11:39 | Gyorgy Rethy | Resolution | fixed => reopened
25-05-2011 11:39 | Gyorgy Rethy | Note Added: 0010047 |
25-05-2011 11:40 | Gyorgy Rethy | Status | feedback => assigned
25-05-2011 13:28 | Gyorgy Rethy | Note Edited: 0010047 |
25-05-2011 14:38 | Gyorgy Rethy | Note Edited: 0010047 |
25-05-2011 14:38 | Gyorgy Rethy | File Added: CR5347_resolution_v2.doc |
25-05-2011 14:40 | Gyorgy Rethy | Note Edited: 0010047 |
25-05-2011 14:40 | Gyorgy Rethy | Note Edited: 0010047 |
25-05-2011 14:56 | Jacob Wieland - Spirent | File Added: CR5347_resolution_v3.doc |
25-05-2011 15:50 | Gyorgy Rethy | Note Added: 0010062 |
25-05-2011 15:51 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
25-05-2011 15:51 | Gyorgy Rethy | Status | assigned => resolved
01-07-2011 15:56 | Ina Schieferdecker | File Added: CR5347_resolution_v4.doc |
01-07-2011 15:57 | Ina Schieferdecker | Note Added: 0010186 |
01-07-2011 15:58 | Ina Schieferdecker | Status | resolved => closed
01-07-2011 15:58 | Ina Schieferdecker | Resolution | reopened => fixed
01-07-2011 15:58 | Ina Schieferdecker | Fixed in Version | => Edition 4.3.2 (interim)

Notes

(0009156)
Ina Schieferdecker
04-01-2010 13:49

We should discuss if defining a synonym for a nested type definition is a wanted feature of TTCN-3 or not. Depending on the outcome, (1) we may exclude type synonyms for nested type definitions or (2) we have to develop a solution. However this is not trivial as pointed out in the examples. Hence, postponed to 2010.

(0009265)
Jacob Wieland - Spirent
23-03-2010 15:37

For consistency, the type R.x should include all values that can be
assigned to field x in type R. Thus, it should include all values
described by the subtypeSpec of field x, as well as the special 'value' omit.
For that, one would need (the idea of) a special type construct like
type integer X optional (1,2);
Entities declared with this type automatically include the special value omit
and thus can be used for the purpose of storing values the same values as
field x.
The problem with this solution is, of course, that suddenly, a type
(which normally only describes non-special values), now also contains omit.
That means that the semantics of the template restrictions for this type
need clarification:
- template(value) R.x => all values of R.x except omit
(as opposed to all of R.x for non-optional field x)
- template(omit) R.x => all values of R.x including omit
(as opposed to all of R.x PLUS omit for non-optional field x)
- template(present) R.x => the same as normally
However, the beauty of the solution lies in the consistency:
It is always possible to use an entity of type R.x to field x in R and the
other way around which is the definition of a compatible type.
If the 'optional' would disappear from the type definition, R.x would be
compatible to field x, but field x would not be compatible to R.x.
While in my opinion, it would be nice to define the above type X as written
also in TTCN-3, it is not really necessary, as one can always just refer
to R.x instead or define X as:
type R.x X;
to arrive at the same semantics for X.
If this solution is acceptable, the following needs to be done:
- describe the semantics of R.x in the section describing dotted notation
on types
- clarify the semantics of the different kinds of declarations,
especially var/const/parameter/template(value)/template(omit)
- define the semantics of a StructFieldSpec with an optional type which does not have an optional modifier:
- either this has the same semantics as if the optional modifier were present
- or this situation is forbidden
- arrays and record of/set of types of such an optional type should also be
- either forbidden or
- explicitly allowed with the expected semantics (i.e. that they can
contain omit as elements) to avoid confusion.
- generelly, matching mechanisms for such a type include the same matching
mechanisms as those for field x, i.e. also omit, * and ifpresent.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If this solution is unacceptable, R.x could be X without the optional part
(this is the proposed solution 1) from the CR)
with the drawback that not all fields x can be used as R.x, i.e.
R.x is compatible with field x, but not the other way around.
Though this is somewhat confusing at first hand, it would still be a
useful definition. It has the advantage that no additional clarifications
or restrictions would need to be introduced, as now R.x can only contain values
again.
The proposed solution 2) from the CR is either not consistent or is alike to
the first solution proposed here, therefore needs no further discussion.

(0009274)
Gyorgy Rethy
24-03-2010 11:04 (edited on: 24-03-2010 11:06)

Currently record/st fields have 3 ortogonal properties:
- name
- type (=valid value set)
- optionality
Optionality is the propoerty of the field itself and not of the type (of the field).
What would happen if making optionality property of the type instead of property of the field?
---------------
In case of simple types:
1) optionality would not be part of TTCN-3 built-in types, otherwise the "optional" in
type record MyRec ( integer f1 optional);
type integer MyOptInt optional;
would not make sense
but this would mean that the user defined type
type integer MyOptint optional;
would extend the built in integer type with one more value that is strange and contradicts the current logic of TTCN-3 (sub)typing.
2) "omit" is member of the built-in types and optional in the record/set field definition shows if omit is accepted in that field or not. Thus "optional" in fields would become a special form of subtyping. In this case
type integer MyOptInt optional;
would make no sense as "integer" already includes "omit".
But what is worse, in
type record MyRec {integer f1};
field f1 should also accept "omit" as omit is member of integer.
This also would mean, that if someone wants to define a type without optional, he/she should write
type integer MyInt (-infinity..infinity);
So, this alternative 2) would not be acceptable as would change the semantics of already existing codes.
Looking at this from the another perspective:
When using simple type variables/parameters in expressions and assigning them to record/set fields, tools today can check the type compile time and shall check if the value is bound runtime. If omit is made a value, tools shall also check that - if the value is bound - it does not contain an omit value (except when assigned to optional fields, where omit is allowed).
This, in practical terms, would alomos double the runtime checks tools has to do, thus decreasing tool performance.
-------------------
In case of structured types:
structured types are unlike the built-in simple types, do not contain any value by definition, the legal set of values are defined by the user. In another words, they are built-in type-construction mechanisms but not built-in types. Therefore, in case of structured types, if he users wants to include "omit" into the value set of his/her type, should specify it directly, like
type union MyUnion { integer a1, integer a2 } optional;
However, this would not be consistent to the definition of simple types, where "optional" would be forbidden (as omit would already been included into the built-in types).
========================
So, to sum up: IF omit would be made a special value in the language, this would increase language complexity; I cannot see a consistent way to handle it; it would open the way for new kind of errors, that could be checked runtime only, thus causing test case error instead of compile time errors, increase tool complexity and as a consequence, decrease tool performance;
Example error:
type record MyRec {integer f1 (-infinity..infinity)};
...
var integer v_int := omit;
var MyRec v_MyRec;
v_MyRec.f1 := v_int;
On the other hand the advantages would be minimal. Therefore I think that this is acceptable, hence we shall go the another way.
========================
When quoting e.g. a record field, only the type property of the field is referenced. E.g.
type record MyRec1 {integer f1 optional (-2..2) };
type record MyRec2 {integer F1 (-2..2) };
Myrec1.f1 and MyRec2.F1 both denotes the type integer(-2..2), though both the name and the optionality propoerties of the referenced fields do differ (but as mentioned above, they are ortogonal to the type propoerty).
All subtype specs. applied to the outer type are ignored as they are not property of the fields at all, it is a property of the outer type. E.g.
type record MyRec3 {integer f1 optional (-2..2), integer f2 } ({omit,1},{1,1});
also denotes the type integer(-2..2), though, when this type is used in field f1 of MyRec3, it cannot take the value e.g. -2.
But this is consistent of using named types in fields, e.g.
type integer MyInt (-2..2);
type record MyRec4 {MyInt f1 optional, integer f2 } ({omit,1},{1,1});
When used in MyRec4, f1 cannot take the value e.g. -2 either, though the type MyInt contains -2 in it value set.

(0009711)
Jacob Wieland - Spirent
03-09-2010 13:14

please review the changes in the document, changes are in sections: 6.2.1.1, 6.2.2.1, 6.2.3.2 and 6.2.5.1

(0009970)
Ina Schieferdecker
14-12-2010 15:29

Not yet finally agreed - hence shifted to 2011 for consideration.

(0010047)
Gyorgy Rethy
25-05-2011 11:39 (edited on: 25-05-2011 14:40)

Reviewing resolution... see my changes in CR5347_resolution_v2.doc.
I oppose to "track back" the contraint applied to the outer type to the inner type for the following reasons:
1) would be backward incompatible; up to know this was not specified explicitly, there are tool implementations ignoring the constraints of the outer type; for the users of these tools the narrower approach would be a non-backward compatible change.
2) According to the current mapping rules, ASN.1 table constraint is mapped to TTCN-3 but relation constraint is ignored. To be consistent with the narrower approach, relation constraint should also be mapped that would result smaller value sets than today, i.e. would be non-backward compatible.
example:
MY-CLASS ::= CLASS {
&Argument OCTET STRING,
&identifier INTEGER UNIQUE }
WITH SYNTAX { INFORMATION &Argument WITH ID &identifier }
myObject-1 MY-CLASS ::= {INFORMATION '00'H WITH ID 1}
myObject-2 MY-CLASS ::= {INFORMATION 'FF'H WITH ID 2}
MySET MY-CLASS ::= { myObject-1 | myObject-2 }
MyMessage := SEQUENCE {
idField MY-CLASS.&identifier ( {MySET} ),
valueField MY-CLASS.&Argument ( {MySET} {@idField} )
}
This, in fact denotes the constraint ({1,'00'H},{2,'FF'H}) to the SEQUENCE.
But its equivalent TTCN-3 type today is:
type record { integer idField (1,2), octetstring valueField ('00'O,'FF'O)};
this allowes the values {2,'00'O} and {1,'FF'O}, that are illegal values according to the ASN.1 spec. and are used for negative testing!
3) types are often defined as embedded types and used later to define values/templates or other types. If using the narrower understanding, it is not possible to extend the set of values later, while with the broader understanding it is possible to resrict the derived type, if needed.
example:
type record MyRec1 { record { integer fInner (1..10)} fOuter }({{1}},{{2}})
type MyRec1.fOuter MyRec2 //this type is a record with an integer (1..10) field
type MyRec1.fOuter MyRec3 ({1},{2}) //this one is a record where the field can take the values 1 and 2 only
But it is not possible the opposite way. Pls. note, often this is the only way to use parameterized ASN.1 types in TTCN-3 -> the parameterized type itself is not importable, but the embedding type using the parameterized type with an actual parameter is imported and, referencing its field, the given instance of the parameterized type can be used in TTCN-3.
4) What about record of types? To be consistent, in case of record of record of-s, the length restriction applied to the outer record of should also be applied to the inner record of...
example:
type record length (5) of record of integer ConstrainedRecordOfInt;
type ConstrainedRecordOfIntg[-] ConstrainedInt; //for consistency this should be a record of restricted to 5 elements...
5) The omit and the record of length transition problem could be handled by extra rules and explanations in the standard, but this would, complicate the language unnecessarily, again something with several exception rules...

(0010062)
Gyorgy Rethy
25-05-2011 15:50

Reviewed by Gyorgy and Jacob, need a final GO from the STF.

(0010186)
Ina Schieferdecker
01-07-2011 15:57

Implemented basically as proposed.