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

ID | Project | Category | View Status | Date Submitted | Last Update
0005961 | Part 01: TTCN-3 Core Language | Editorial | public | 21-11-2011 11:54 | 09-08-2012 13:54

Reporter | Bogdan Stanca-Kaposta |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.5.1 (published 2013-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | 15.8.c (page 121) of ETSI ES 201 873-1 V4.3.1 (2011-06)
Source (company - Author) | STF 433

Summary | 0005961: Table of template restrictions is wrong

Description

The Table 14: "Restricting modified templates" is wrong since the a template of a stronger constraint can always be safely modified (same as cast in object oriented languages) to a weaker constraint.
e.g.
templates of kind template(omit) or template(value) can be modified to template(omit)
// definitions of restricted templates
type record ExampleType {
integer a,
boolean b optional
}
template(value) ExampleType exampleValue:= { 1, true };
template(present) ExampleType examplePresent modifies exampleValue := { a := ? };

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR5961_resolution_v1.doc (121,856) 19-07-2012 17:06 http://oldforge.etsi.org/mantis/file_download.php?file_id=2704&type=bug

Issue History
Date Modified | Username | Field | Change
21-11-2011 11:54 | Bogdan Stanca-Kaposta | New Issue |
21-11-2011 11:54 | Bogdan Stanca-Kaposta | Clause Reference(s) | => 15.8.c (page 121) of ETSI ES 201 873-1 V4.3.1 (2011-06)
21-11-2011 11:54 | Bogdan Stanca-Kaposta | Source (company - Author) | => STF 433
28-11-2011 09:20 | Gyorgy Rethy | Note Added: 0010326 |
28-11-2011 09:27 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-11-2011 09:38 | Gyorgy Rethy | Note Edited: 0010326 |
28-11-2011 09:38 | Gyorgy Rethy | Target Version | => Edition 4.4.1
28-11-2011 09:58 | Jacob Wieland - Spirent | Note Added: 0010330 |
28-11-2011 15:21 | Gyorgy Rethy | Note Added: 0010353 |
29-11-2011 14:26 | Jacob Wieland - Spirent | Note Added: 0010400 |
30-11-2011 10:49 | Gyorgy Rethy | Note Added: 0010427 |
30-11-2011 10:49 | Gyorgy Rethy | Target Version | Edition 4.4.1 => v4.7.1 (published 2015-06)
10-07-2012 19:29 | Gyorgy Rethy | Note Added: 0010780 |
10-07-2012 19:29 | Gyorgy Rethy | Status | new => closed
10-07-2012 19:29 | Gyorgy Rethy | Resolution | open => won't fix
11-07-2012 10:16 | Jacob Wieland - Spirent | Status | closed => feedback
11-07-2012 10:16 | Jacob Wieland - Spirent | Resolution | won't fix => reopened
11-07-2012 10:16 | Jacob Wieland - Spirent | Note Added: 0010808 |
12-07-2012 15:51 | Gyorgy Rethy | Note Added: 0010891 |
12-07-2012 16:11 | Jacob Wieland - Spirent | Note Added: 0010894 |
12-07-2012 16:23 | Jacob Wieland - Spirent | Note Edited: 0010894 |
19-07-2012 17:02 | Gyorgy Rethy | Note Added: 0010941 |
19-07-2012 17:02 | Gyorgy Rethy | Status | feedback => assigned
19-07-2012 17:02 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
19-07-2012 17:05 | Gyorgy Rethy | Note Edited: 0010941 |
19-07-2012 17:06 | Gyorgy Rethy | File Added: CR5961_resolution_v1.doc |
07-08-2012 15:44 | Jacob Wieland - Spirent | Note Added: 0010985 |
09-08-2012 08:58 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
09-08-2012 08:58 | Gyorgy Rethy | Status | assigned => resolved
09-08-2012 08:58 | Gyorgy Rethy | Resolution | reopened => fixed
09-08-2012 08:58 | Gyorgy Rethy | Fixed in Version | => Edition 4.5.1
09-08-2012 13:54 | Ina Schieferdecker | Note Added: 0011007 |
09-08-2012 13:54 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010326)
Gyorgy Rethy
28-11-2011 09:20 (edited on: 28-11-2011 09:38)

In principle anything could be modified to anything else. The purpose of $15.8 restr. c) is to disallow this kind of anything-to-anything modification. Therefore anyone specifying a base template with a certain restriction can be sure that all children modified templates inherit the restriction and cannot override the limitation. Think about SW libraries, where both base templates and API functions are defined with a certain restriction in mind and API function calls cannot fail until the user of the API is calling the functions with modified templates based on the base templates of the lib.
Anyone who wants to have modified templates with weaker restriction shall base them on a base template with weaker restriction.
I propose is to reject the CR.

(0010330)
Jacob Wieland - Spirent
28-11-2011 09:58

First of all, weakening the restriction is NOT an "anything-to-anything" restriction, but a cleanly defined one. It is the only one which can be done safely without having to do additional checks on the modified template (other than in the strengthening restriction where the whole template needs to be re-evaluated to see if it fits the new stronger restriction).
To keep the restriction of the template-to-be-modified or make it stronger in the modifying template does not make any sense whatsoever, in my opinion. If this CR is rejected, then I propose to not relate the restrictions of modified and modifying templates whatsoever as it is simply confusing that nonsensical relations are allowed and sensible ones are disallowed.
In principle, from the user point-of-view, modifying templates is just a shortcut way or re-using already existing templates. The user should be free to use this feature to their best advantage (whatever that might be in different cases).

(0010353)
Gyorgy Rethy
28-11-2011 15:21

STF discussion 28/11: relaxing is requested due to a use case, where templates are derived from traces and those templates be used as bases for both sending and receiving. One option could be to require compatibility by definition in table 13. However, this would cause backward compatibility problems. the proposal needs further discussion to find a common solution. Add an example for both use cases.

(0010400)
Jacob Wieland - Spirent
29-11-2011 14:26

To summarize my understanding of the discussion:
As far as I understood it, table 14 was introduced to add a restriction that should help the developer of a testsuite which uses some library api which requires certain restricted templates that should be derivations of some base template as parameters and should be safe in doing so.
The argument is that if the restriction in Table 14 is lifted, tools would not be able to impose that restriction on the usage of the api, i.e. the user would be allowed to give templates derived from the base template which would have weaker restrictions than the base template, leading to potential problems at runtime. To avoid this, a non-syntactical relationship between the base template and the derived template is assumed such that the derived template can safely be used where ever the base-template could be used. It is assumed that other ways of ascertaining the safe usage of templates do not exist.
In my opinion/experience, this is not true, as it is possible at compile time for most template expressions to determine whether they respect the demanded template restriction or not by inferring the *actual* template restriction of the expression. Only for those template expressions where this cannot be ascertained, so that the expression *maybe* can fulfill the restriction, a runtime check is necessary in all places where the restriction shall be imposed. In the case that the restriction *cannot* be fulfilled, a compile-time error can be issued. This will be the case (regardless of the removal of table 14) if, for instance, any *actual* present-, omit- or unrestricted-template is given as actual parameter to a value-template formal parameter and then used in its definition.
The inference of the *actual* restriction of a template (in contrast to the *declared* template restriction) must take into account the template-restrictions of its formal parameters (if any) and the actual inferrable restriction of the base template (for derived templates) and of course the sub-expressions of the template.
Even in the presence of table 14 it is not always possible to ascertain that a parameterized value-template that is derived from another value-template is an *actual* value-template (e.g. if it has unrestricted formal template parameters or uses unrestricted template variables). In that case, a runtime check to see if the demanded value-restriction is respected for an instantiation of that template must be done anyway.
So, keeping the restrictions of table 14 does not achieve anything as templates that are declared as having the right restriction could still have the wrong restriction (depending on their parameter instantiations) while templates that have the wrong restriction declared but *could* have the right restriction, also depending on the instantiation of their parameters, cannot be rejected, either.
For me, this can only lead to the conclusion that table 14 can be safely removed without any repercussions whatsoever. I will gladly revise my opinon if someone can show me a scenario where at compile-time it cannot be ascertained that a template-restriction is fulfilled if the restriction of table 14 is lifted where it could be ascertained if it was not.

(0010427)
Gyorgy Rethy
30-11-2011 10:49

As we have no consensus and only 3 days left from the STF's last working session, this issue has to be shifted to 2012.

(0010780)
Gyorgy Rethy
10-07-2012 19:29

Template restrictions was introduced on 3GPP request and be suitable to TF160's use cases. The current CR doesn't provide a use case, while changing the standard would need a reason.

(0010808)
Jacob Wieland - Spirent
11-07-2012 10:16

We provided a use case - see your own comment above. So, the CR still is warranted.

(0010891)
Gyorgy Rethy
12-07-2012 15:51

It was not my comment, it says "STF discussion 28/11": I have just noted what was told during a working meeting. The relation of this use case to the CR to be clarified, as any templates retrieved from traces can be defined as simple templates without restictions and to derive any other kind of templates from it - with or without restriction, as needed.

(0010894)
Jacob Wieland - Spirent
12-07-2012 16:11 (edited on: 12-07-2012 16:23)

Unfortunately, this is not true.
If I do not generate the templates as value-templates - even though they ARE in effect value-templates -, then it is not allowed for me to use them in places where only value-templates are accepted. This is an unacceptable restriction.
Thus, this would force me to generate the templates as unrestricted templates and then derive new value-restricted templates from them which do not change anything. Since the number of templates should be kept as small as possible for the purpose of usability and not cluttering of the namespace, this is also unacceptable.
The main problem that I still have, though, is, that the table introduces this restriction to achieve a goal which is not achieved. This makes the table not only couterproductive to our use case, but useless for the use case it was introduced for, as well.

(0010941)
Gyorgy Rethy
19-07-2012 17:02 (edited on: 19-07-2012 17:05)

I have checked it with TF160 and lifting this limitation would not cause a problem for them. Therefore I'm not opposing any more, we can go ahead. See proposed solution in CR5961_resolution_v1.doc.

(0010985)
Jacob Wieland - Spirent
07-08-2012 15:44

I agree.

(0011007)
Ina Schieferdecker
09-08-2012 13:54

as proposed.